Managing production feedback

Start in the feedback index. Each request is one feedback item file in docs/feedback/items/, which owns its current status and next action; run ./v3 feedback check and ./v3 feedback index after editing. The production feedback register, dated summaries and triage are historical evidence; detailed feature plans retain implementation/approval records.

Intake and identity

1. Search the items (grep -ril <words> docs/feedback/items) and linked older inventories for the reported outcome and source-post ID. Match by intended behavior and acceptance conditions, not shared keywords or shared source alone.

2. For a new outcome, allocate an unused permanent ID PF-YYYYMMDD-Fnn or PF-YYYYMMDD-Bnn (or PF-YYYYMMDD-Onn for other) using the intake date/category and next unused number, and create docs/feedback/items/<ID>.txt. Never renumber or reuse retired IDs. List the exact report under Sources:, with the parent post and full thread when they add context; retain every batch/category/item alias, request nuance and import limitation. Label unknowns.

3. Add workflow state, delivery evidence/date/limits, completion checks, next action, inherited estimate/provenance, proposed workflow and existing plan/evidence links. Use the minimal triage process for benefit/effort/uncertainty; preserve original estimates separately from revised scoped estimates. Scores and recommendations never authorize implementation.

4. Repeated reports of the same outcome add sources/aliases to the existing request. Distinct outcomes get separate linked requests. Uncertain duplicates stay separate with a review next action; older unreconciled inventories remain explicitly outside migrated coverage.

Updates and closure

Update current fields in the item only, in the same commit as the work, with a Feedback: PF-... commit trailer per item (see AGENTS.md); each triage run proposes status updates for items a commit named but left unchanged; append dated evidence or a concise correction reason when changing claims. Detailed evidence stays in linked triage/feature documents. Historical status tables are snapshots and must link to the items, rather than become a second current-status list.

Workflow: untriaged needs scope/evidence review; ready has clear checks and a proposed next action; planned links an approved plan and its approval boundary; in progress has authorized active work; blocked names the unmet prerequisite and next recovery action; closed items use done, declined, superseded or duplicate and record the disposition and evidence. In item files these states are written lowercase with in-progress hyphenated. An inherited recommendation or a drafted plan alone is not approval. Local work awaiting deployment may remain blocked with deployment as its next action.

Delivery evidence: unknown/pending, locally verified, deployed, production accepted. Record applicable platform/surface, date and links; these are evidence claims, not automatic workflow transitions. Do not erase a known local result because deployment is unknown. Production acceptance requires evidence against this request's completion checks in the reported environment; adjacent improvements do not establish closure.

Close only with completion evidence and any required production acceptance, or an explicit maintainer disposition (declined, superseded, duplicate) linked to its reason/target. Preserve unresolved checks. Reopen on contrary evidence with the new report, prior closure context and next action. Posting a source-comment reply requires explicit authorization; it is not implied by maintaining an item.

Corrections and recovery

Review diffs/Git history before correcting mistakes; avoid broad resets. For a mistaken merge, restore distinct request records and original aliases/sources, link the correction in both records and recheck coverage. A deliberate merge retains the retired ID as a closed duplicate pointing to the surviving request; transfer all aliases/reports. Splits preserve the original ID as a relationship record and link the separately scoped outcomes. Never silently delete identity or evidence.

Illustrative walkthroughs (not live actions): a new F07 report of the same default-port behavior adds a source to that request; an explicit-port behavior report stays separate. A scoped F03 with defined checks may move to ready, but implementation still needs authorization. Local F02 verification does not imply deployment; deployment evidence alone does not imply production acceptance. A contrary F02 report reopens any later closure. If F08/F09 were mistakenly merged, restore both outcomes with their shared source retained and document the correction.