fix(stories): use the global default validation strength

[agarwal-ishaan]

Summary

• Default story workflows to DEFAULT_STRENGTH instead of 0.2.
• Warn when pdd detect --stories is explicitly run below the 0.5 recommended floor.
• Update the concise analysis and user-story implementation prompts.
• Update README and user-story workflow documentation.
• Rotate the verification-profile requirements and hashes for both changed prompt files.
• Cover the default and warning behavior.

Fixes #2394

Tests

• python -m pytest tests/test_user_story_tests.py tests/commands/test_analysis.py -q
• Rotation hashes verified against the exact changed prompt and profile bytes.

[gltanaka]

Request changes — Tier A, full-diff review at 3428d90

The default change in detect --stories is directionally reasonable, but this head is not safe to merge.

P1 — The prerequisite gate is not in the base

#2394 says this floor becomes meaningful after the bounded gate in #2390, and its own measurement says the legacy open-ended gate fails correct prompt sets at 0.2, 0.5, and 0.9. However, this PR is based on 0faf7be; that base still calls detect_change() and treats an empty change list as the verdict. PR #2390 is a separate, open, conflicting PR with failing checks. Merging #2398 first therefore raises cost without establishing a sound validator and can turn correct stories red.

Please make the ordering real: land #2390 first (or rebase this work onto an equivalent protected bounded-gate implementation), then validate the combined head. The PR body should state this dependency.

P1 — Several real story gates still force the proven-bad tier

Changing the helper defaults does not affect callers that explicitly pass 0.2:

• pdd/agentic_change_orchestrator.py:3767 passes strength=0.2 into _generate_user_story_artifacts_for_change; under strict story policy that value reaches run_user_story_tests at line 1549 and remains a blocking gate.
• pdd/commands/fix.py:216 makes plain pdd fix story__*.md use 0.2 for both initial detection and post-fix validation. I reproduced an implicit invocation forwarding 0.2 while DEFAULT_STRENGTH was 1.0.
• pdd/commands/generate.py:863,906 still forces 0.2 for story linking/authoring; the linking path invokes detect_change, and existing tests explicitly preserve the stale value.

Update all validation call paths (splitting low-cost authoring from validation if intentional), add implicit/default tests, and back-propagate the behavior into the corresponding PDD prompts. Otherwise the root failure from #2394 remains reachable even after this PR.

P1 — The verification transition grants itself authority and is invalid on the actual protected base

docs/ci.md requires requirement-transition authority to be installed dormant in one protected Phase A and consumed only in a later Phase B. This PR adds/retire/reissues rows while changing the two prompts and .pdd/verification-profiles.json in the same change.

There are also two deterministic byte/history defects:

• New schema-3 rows were inserted before protected rows (commands/analysis appears before the existing code_generator_main row), so candidate_rows[:len(protected_rows)] != protected_rows; production validation raises candidate retirement history is not append-only.
• The actual committed profile SHA is c97795d274f7392088b127f3daef4081f4e124c75ec66ccd4d49b71a4b382a7d, but the new rows, verifier constant, and test bind 0d6fd425..., a synthetic state that omits the protected #2378 Zsh rotation.

Prepare an append-only dormant Phase A against the current protected bytes, merge it, and consume it in a separate Phase B. Do not fix this only by changing an expected hash.

Validation

• python -m pytest tests/test_user_story_tests.py tests/commands/test_analysis.py -q: 154 passed.
• Three focused rollout-policy tests locally: 3 failed, reproducing the committed c97795... versus expected 0d6fd4... mismatch and stale transition bindings.
• Required GitHub unit job: 5 failed / 16,385 passed; four rollout failures are caused by this PR. The remaining dep_test.py xdist race appears pre-existing and unrelated.
• Prompt artifacts for the changed user_story_tests generated module are present, its architecture.json mapping remains present, and the prompt changes are at appropriate behavioral altitude. analysis.py and verification policy code are human-maintained under repository ownership. Any added caller fixes must update their prompt sources too.

The submitted tests exercise the direct default and warning with mocks, but there is no contributor end-to-end result for the combined bounded-gate + default-strength branch, nor coverage of the strict change/fix call paths above. That evidence is required after the dependency and policy phases are corrected.

[gltanaka]

Re-review of updated head 158b11d: the runtime propagation changes are good, the focused story/change suites pass (274 tests locally), and all current GitHub checks are green. I am still requesting changes because the release-integrity path remains invalid.

1. P1 — the real protected-base transition is still rejected. Building the production manifest with base 0faf7be4 and head 158b11d, then calling load_verification_profiles, raises candidate retirement history is not append-only. The protected policy has 58 requirement-rotation rows and the candidate has 60, but candidate[:58] != protected; the first mismatch is index 35 because the new story rows were inserted before protected history at verification-profile-rotations.json#L398. The replacement rows also bind base profile 6e589170..., not the actual protected profile 0fcb1bb3....

2. P1 — this PR still installs and consumes its own authority. docs/ci.md#L30-L57 explicitly requires separate protected Phase A and Phase B changes and forbids same-PR installation/consumption. The new exact-state branch at verification.py#L3201-L3207 does not repair that transition: on stationary HEAD it keeps only the two rows whose head_policy_sha256 equals 73051b... and discards the other 54 active rows before validation. That explains why stationary tests and CI are green while the protected-base production path fails.

3. P1 — generated-code sources are out of sync. Runtime run_agentic_change now accepts strength, but both its prompt interface and requirement and architecture.json interface omit it; the prompt then references an undeclared strength at line 44. The orchestrator prompt also specifies strength=DEFAULT_STRENGTH for story generation rather than forwarding strength. A normal regeneration can therefore remove the public parameter, emit an undefined name, or silently discard an explicit CLI value.

Required before merge: split authority installation and consumption into protected phases; keep rotation/retirement history append-only and bind the actual protected bytes; remove the broad digest filter and add a test for the actual protected-base-to-candidate loader path; then synchronize both prompt interfaces/requirements and architecture.json with the runtime signatures and forwarding behavior.

[gltanaka]

Re-review of updated head b8201fd: the contributor fixed the runtime/prompt/architecture.json drift, explicit strength is forwarded correctly, and the focused story/change suite passes locally (274 tests). The current head still must not merge.

1. P1 — required CI and production verification are red. GitHub reports this PR as CONFLICTING against current main and the required unit job fails four deterministic rollout-policy tests. Locally, production loading for the PR parent 7b85d710..b8201fd and stationary HEAD..HEAD both return:

   • pdd/prompts/detect_change_python.prompt: requirement transition bindings mismatch
   • pdd/prompts/sync_determine_operation_python.prompt: requirement transition bindings mismatch

   These are the same failures present in CI, not unrelated flakes. The story-strength behavior tests pass; the release-integrity gate does not.

2. P1 — the new remediation self-authorizes the consuming change. The rotation policy is byte-identical between parent and head; no authority-only Phase A was protected. Instead, verification.py#L1064-L1131 hard-codes seven exact transitions in the same commit that changes those prompts and profile entries, injects them into authority at verification.py#L3430-L3447, and suppresses new-authorization validation at verification.py#L3541-L3553. The comment says this is used because dormant retirement cannot be proven while the profile changes in the same candidate. That is precisely the same-change authorization that docs/ci.md#L30-L57 forbids.

3. P1 — the branch is stale against current main. Main is now 60588697, which independently advances agentic_change_orchestrator_python.prompt, the profile registry, verification code, and rollout tests. GitHub identifies conflicts in those overlapping areas. The bridge here is pinned to parent profile faf427d3..., while current main is 85d01008...; direct current-main-to-head loading produces 42 invalid reasons. The exact bindings must be prepared again after resolving current-main semantics.

Before merge: establish and merge a genuinely authority-only Phase A against current main, then consume that protected authority in a later Phase B without adding a repository-specific same-change bypass. Rebase the behavioral change onto current main and require the actual protected-base-to-candidate production loader plus the full required CI lane to pass.

[gltanaka]

Re-review of updated head 1ef7a3b: the rebase onto current main resolves the merge conflict, and the behavioral implementation remains sound. Runtime, prompts, and architecture.json agree; the focused story/change suite passes locally (274 tests). The PR still must not merge because its protected verification state is invalid.

1. P1 — required unit CI now has eight deterministic policy failures. Failures include test_rollout_profiles_cannot_self_authorize, profile reconciliation/coverage, the actual protected transition, and dormant rotation checks. This is not an unrelated flaky lane.

2. P1 — the rebase retained stale exact-byte bindings. The protected parent profile is 85d01008... and the candidate file is actually dc13ab15..., but verification.py#L258-L265 still binds the pre-rebase profile state and candidate 44b988c0.... Likewise, current main advanced agentic_change_orchestrator_python.prompt to 35bc6765...; the rebased candidate is 389e3195..., while its composed transition/profile row still expects the old a5f609c2... -> 459fb83c... pair. Production loading 60588697..1ef7a3b reports 36 invalid reasons, including missing/incomplete profiles and transition-binding mismatches; stationary HEAD..HEAD still reports 17 invalid reasons.

3. P1 — the same-change authorization bypass remains. verification.py#L1106-L1173 creates seven repository-specific in-code authorizations in the same commit that changes their prompt/profile bytes, injects them into authority at verification.py#L3539-L3550, and suppresses new-authorization validation at verification.py#L3650-L3657. The code comment explicitly says dormant retirement cannot be proven in this candidate. Per docs/ci.md#L30-L57, that requires a separately protected authority-only Phase A; it cannot be replaced by a same-PR bootstrap exception.

Required before merge: remove the same-change in-code authority, prepare and merge a genuine authority-only Phase A against current main and exact prepared bytes, then consume it in a later Phase B. The real protected-base-to-candidate and stationary production loaders must both return zero invalid reasons, and the full required unit lane must pass. Updating expected hashes alone would not address the authorization defect.