Feature plan: Step 1 · Step 2 · Step 3 · Step 4

Debug mode: enabled. Effort study: railspike-effort / v3/production_feedback_management; standing P2 enrollment.

Completion Contract

• Documentation-only for maintainers/contributors: planning index → register → request/source/plan → evidence-backed update or closure. Cover all 16 October 21 entries; preserve aliases, sources, inherited estimates and verification limits. Older inventories remain linked and unreconciled.

• Allowed files: docs/plans/production_feedback_register.md, docs/reference/production_feedback_management.md, October 21 summary and mini-triage, docs/reference/minimal_feedback_triage.md, docs/plans/README.md, this cycle's artifacts and docs/plans/effort_estimation_trial.md. These names resolve to the exact paths in approved Step 2; cycle-folder organization/reference repairs follow Railspike.

• Recovery: reviewable corrections/Git history, retained retired IDs/source aliases and explicit reopen/merge/split rules. Completion requires coverage, document/link integrity, status/evidence consistency and a documented intake-to-correction walkthrough. No production resolution is inferred.

• Application/runtime, tests/CI, generated assets, deployment, production writes, external components and todo.txt are outside scope. Runtime/UI/deployment checks are inapplicable. Dependency delta: zero; no dependency approvals needed.

Key Risks

• High risk: false resolution or lost provenance. Compare summary/triage/evidence before status assignment; retain conflicting/unknown claims and map every original alias/source before redirecting readers.

• High risk: duplicate authority or mistaken merges. Establish register ownership first; migrate distinct outcomes separately, flag historical overlap, and retain old context with explicit historical labels.

Stage 1 — Intake guide and first requests

• Goal: usable intake/update path with October 21 F01–F03.

• Dependencies: Step 3 approval, branch and organized-plans commit; implementation summary created afterward.

• Expected changes: guide defining IDs/fields, matching, workflow/delivery states, approval, closure/correction; first three request records.

• Verification approach: trace aliases, sources, estimates and checks; walk through add/match/update/reopen using documentation examples.

• Risks or open questions: F02 local verification must retain pending deployment; resolve field ambiguity before expansion.

• Canonical components/API contracts touched: new register/guide, existing minimal triage meanings; no runtime contracts.

Stage 2 — Remaining feature requests

• Goal: cover F04–F11 with a short proposed next-work list.

• Dependencies: Stage 1 verified/committed with summary update.

• Expected changes: eight records preserving evidence, estimates and distinct outcomes; next picks with benefit/effort/uncertainty and approval limits.

• Verification approach: trace all 11 feature aliases; preserve separate F08–F10 outcomes despite shared sources; inspect F06 LCD evidence.

• Risks or open questions: older triage predates LCD completion; date evidence, flag conflicts and preserve historical assertions.

• Canonical components/API contracts touched: register; existing feature evidence read-only.

Stage 3 — Bugs and discovery

• Goal: complete the batch and establish current-status authority.

• Dependencies: Stage 2 verified/committed with summary update.

• Expected changes: five bug records; parent/thread provenance, import limits, index/guide links and historical labels/register mappings in October 21 documents and minimal triage.

• Verification approach: account for all 16 aliases/sources/estimates; retain B03 local limits and B04 historical relationships; follow index → register → evidence.

• Risks or open questions: historical tables could appear current; conspicuous authority labels retain old evidence without migrating older batches.

• Canonical components/API contracts touched: register/index, October 21 inventories, minimal triage guide; no application surfaces.

Stage 4 — Acceptance and closeout

• Goal: verify the maintainer workflow and record delivery/follow-ups.

• Dependencies: Stage 3 verified/committed with summary update.

• Expected changes: in-scope corrections; summary and ledger closeout; older-batch reconciliation follow-up.

• Verification approach: manually compare all 16 mappings against original nuances/links/estimates; check unique IDs/aliases, local links/anchors, status evidence and historical labels; walk through intake, duplicate review, progress, closure, reopen and mistaken-merge correction. Check diff/file scope and zero dependency delta; run git diff --check.

• Risks or open questions: counts conceal semantic loss; manual comparison gates closeout, with maintainer study acceptance pending.

• Canonical components/API contracts touched: approved documentation only; no runtime tests or external actions.

Execution and study checkpoint

Step 2 explicitly approved; storage clarification confirms repository Markdown, no scope change. After Approved Step 3, create a feature branch and organize artifacts under docs/plans/production_feedback_management/, repairing links/index before the approved-plans-only planning commit. Keep ledger bookkeeping outside that initial commit and include it in closeout. Each stage must finish verification, update the implementation summary and commit before the next begins.

Step 3 handoff, 2026-10-23T09:51:06Z: 0.35 projected total reaffirmed, scope v1/R1/P2, Codex single exposed rater, original baseline 1a358bc9be3cdb725277c792625a678e7bc85436. Includes planning, migration, required document verification and Git recovery. Additional exposure: planning index, minimal triage and LCD implementation record; no independent rating or measured work. Exact R1 sources remain those hash-verified at Step 2; prior snapshots preserved. No implementation/accepted outcome; awaiting Approved Step 3.