Track security defaults in v4.x: missing patterns fallback led to fail-open behavior

[jnpkr]

Context

There is an open PR that addresses a major part of this:

• Related PR: feat: hook test harness + SecurityValidator patterns template #859 (adds test harness, SecurityValidator tests, and patterns.example.yaml)
  Thank you — this is a strong improvement.

Why open this issue

This issue tracks the broader/default-security posture so it remains visible until fully resolved across release/install paths.

Problem observed

In v4.x, SecurityValidator.hook.ts references:

• PAI/USER/PAISECURITYSYSTEM/patterns.yaml
• fallback: PAI/PAISECURITYSYSTEM/patterns.example.yaml
  When neither exists, behavior is fail-open (all operations allowed), which weakens defense-in-depth.

What the linked PR improves

• Adds missing patterns.example.yaml
• Adds hook test harness + SecurityValidator coverage
• Verifies expected block/confirm/allow behavior

Remaining checks / acceptance criteria

• Confirm fresh install path always results in a valid patterns file present
• Confirm upgrade path from older installs preserves/enables secure defaults
• Add CI gate to prevent release artifacts from shipping without fallback patterns
• Document expected fail mode if patterns cannot be loaded (preferably not fully permissive)
• Re-evaluate settings.json default permissions vs least-privilege goals

Notes

If #859 fully closes all items above, this issue can be closed as complete.
Otherwise, keep this as the follow-up tracker for residual risk.

[rikitikitavi2012-debug]

Our PR #859 (test harness + patterns.example.yaml) addresses most of the acceptance criteria here. Specifically:

• ✅ Adds patterns.example.yaml as fallback for fresh installs
• ✅ Adds SecurityValidator test coverage verifying block/confirm/allow behavior
• ✅ Tests verify fail-open behavior when patterns file is missing (documented)

For the remaining items (CI gate, upgrade path preservation), those would need separate PRs. Happy to work on those if #859 gets merged first.