feat: Make security baseline extension default-enabled (opt-out instead of opt-in)

[ai-ram-ramani]

Summary

Changes the security baseline extension from opt-in to default-enabled (opt-out). Security rules are now loaded and enforced from workflow start. Users can explicitly disable them during Requirements Analysis if needed (e.g., for throwaway PoCs).

Motivation

Security should be on by default — requiring users to opt in means most projects run without security rules unless someone actively remembers to enable them. This change flips the default so the path of least resistance is the secure path.

Changes

security-baseline.opt-in.md

• Added **Default**: Enabled metadata flag
• Changed prompt from opt-in multiple choice (A=Yes, B=No) to opt-out informational (type disable to turn off, otherwise leave blank)
• Added Loading Behavior section documenting immediate load at workflow start

core-workflow.md (Extensions Loading section)

• Added step 3: check each *.opt-in.md for **Default**: Enabled
• If present: load full rules file immediately (default-enabled behavior)
• If not present: existing deferred opt-in behavior unchanged
• Added Default-Enabled Extensions subsection documenting the opt-out flow
• No-answer behavior: default-enabled extensions stay enabled

requirements-analysis.md (Step 5.1)

• Renamed from Extension Opt-In Prompts to Extension Opt-In / Opt-Out Prompts
• Now handles both flows: opt-out for default-enabled, opt-in for standard
• State tracking table includes Default column (On/Off)
• Documented no-answer behavior for both extension types

Backward Compatibility

• Property-based testing extension is unchanged (still opt-in)
• Any existing extension without **Default**: Enabled in its opt-in file behaves exactly as before
• The **Default**: Enabled flag is additive — only extensions that declare it get the new behavior

Testing

Validated end-to-end in Kiro IDE:

Test 1: Default behavior (keep enabled)

1. Workflow starts → security rules loaded immediately ✅
2. Requirements Analysis presents opt-out question ✅
3. User leaves answer blank → security stays enabled ✅
4. Requirements document includes security rule applicability mapping ✅

Test 2: Explicit opt-out (disable)

1. Workflow starts → security rules loaded immediately ✅
2. Requirements Analysis presents opt-out question ✅
3. User types "disable" → extension marked as disabled in aidlc-state.md ✅
4. Subsequent stages do not enforce security rules ✅
5. Audit log records the opt-out decision ✅

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[scottschreckengaust]

The contributor statement is missing. Extensions being on by default (opt-out) vs. optionally enabled (opt-in) is interesting. The RFC for extensions and PR to choose which extensions are enabled in one question should be reviewed:

• RFC: Community Extensions Framework #225 -> feat(extensions): B+C extensions framework with NIST 800-53 compliance extension #239

[raj-jain-aws]

Why should it be loaded "immediately at workflow start"? Shouldn't the loading behavior still be the same, just that opt-in language becomes opt-out language?

[ai-ram-ramani]

sorry i don't understand. We want it to be security by default, so always loaded during workspace detection but if opted out then security rules are not considered. It did work for me, but I don't think it undid the context add.