Ticket Feedback

Feedback

The edge that closes every loop in the delivery flow. Something came back wrong — the analysis misread a criterion, the exploratory round turned up a fact that changes a row, the master prompt's run produced the wrong thing — and this phase takes the correction, in your words, and lands it in the artifact that owns it. It writes no production code and it decides nothing on its own.

The feedback is the argument. /ticket-feedback the empty-collection case must 404, not return an empty list — product confirmed. Sentences are fine; a list is fine. With no argument it uses the correction already in the conversation, and asks rather than guessing if there is more than one thing there.

Why a phase at all, rather than just saying it. A correction spoken into a session is gone next week and gone in the next session, and it was never anywhere the pull request could quote. That is not a hypothetical: "the same clarification is requested twice on one ticket" is already a named failure of TICKET-ANALYSIS.md §7, and it happens because answers stay in conversations while documents keep the questions. This phase exists to make the correction land in a file, and to say what that correction just invalidated.

Contents

0. What has to be true first
1. Name the target before changing anything
2. Classify it
3. Landing it
4. What it invalidates downstream
5. What feedback is not
6. Failure modes
7. Checklist

0. What has to be true first

Confirm you can open 00-REFERENCE-ARCHITECTURE.md and the guides under docs/guides/. If you cannot, stop and say so. Feedback routinely turns into a rule — "we always translate at the edge" — and a rule applied from memory is the failure this repository exists to prevent, arriving in the most casual possible wrapper.

And there has to be an artifact to correct. An analysis, a master prompt, a diff, a review. Feedback with nothing to land in is a conversation: say so, and point at /ticket-analysis, which is where a ticket with no analysis starts.

1. Name the target

Say which artifact this feedback belongs to, in one line, before you change anything — and say it out loud in the reply, because getting this wrong is how a scope change gets filed as a typo.

One correction can land in two places — a misread criterion is both a wrong row and wrong code — and then it lands in both, upstream first. Never fix the downstream artifact alone. Code patched to match feedback the analysis still contradicts leaves two documents disagreeing, and the next person to read them cannot tell which one is current.

Where you cannot tell which row it is, ask. Feedback you cannot place is a question, not a mandate: guessing produces a confident rewrite of things nobody asked you to touch, and that is worse than a clarifying question by a wide margin.

2. Classify it

Four kinds. They land differently, so name the kind explicitly:

• New information — a fact the analysis did not have, usually the answer to an open question. It closes something. Record the answer and who gave it: an answer with no attributor cannot be re-checked when it turns out to be wrong.
• A correction — the analysis had it and had it wrong. This is the expensive kind, because things were derived from it. §4 is about that.
• A scope change — the ticket itself moved: a criterion added, dropped or altered. Not a correction to the analysis; a change to what is being analysed. The table gains or loses a row, out-of-scope is restated, and §6's conditions are re-tested and re-decided by a person. Say plainly that scope changed, and what it now excludes.
• A preference — how, not what: a naming convention, a shape you prefer, a structure you find clearer. Record it as a decision on this ticket, applied because you asked. It does not become a rule. §5 is why.

If one message carries several of these — it usually does — split them and land each one, rather than treating the whole message as the most convenient kind.

3. Landing it

The change goes in the document. The reply is the diff, not the record.

• Amend, do not regenerate. Change the rows the feedback touches and leave the rest alone. A regenerated analysis costs the decisions the earlier rounds bought, and hides the loss behind output that looks the same (TICKET-ANALYSIS.md §2).
• Strike answered questions; do not delete them. Keep the question, its answer, and who answered. A question that disappears is indistinguishable from one never asked.
• Append to the revision log — what changed, what closed it, what is still open.
• Quote the feedback in the document, in the words it arrived in. Your restatement of it is already an interpretation; the original is what someone will want in three weeks.
• Cite what the change rests on. If the feedback made a row move to another layer, the row cites the principle that puts it there (P3), not "as discussed".

Then report, in the reply: which artifact, which rows, which questions closed, which conditions in §6 moved, and what is now stale downstream (§4). Nothing else — this phase does not take the opportunity to improve the parts nobody mentioned.

4. What it invalidates

A correction upstream makes everything derived from it stale. Saying so is most of this phase's value, because staleness is silent: a master prompt generated last hour still reads perfectly after the row it came from changed.

The master prompt is regenerated, never hand-edited — including here, where editing it is most tempting because the change looks like one word. An edited prompt has no source and disagrees with its analysis silently (GENERATE-MASTER-PROMPT.md §5).

Where code exists against a row that just changed, name the files and stop. Rewriting them is IMPLEMENTATION-PHASE.md's job, with its pre-analysis and its tests; doing it from inside a feedback round produces an untested edit made in the document phase, which is how a delivery flow quietly stops having phases at all.

5. What feedback is not

• Not a way to widen scope quietly. "While you're in there" is a scope change: it gets a row, or it gets refused in writing. Both are cheap here and expensive later.
• Not a source of architectural rules. A preference recorded on this ticket is a preference. It becomes a standard when it is written into a guide and cited from there — that is the whole difference between this estate's rules and an opinion in the architecture's clothing.
• Not a way to close a question by discussing it. A question closes on an answer, with an attributor. "We talked about it" closes nothing.
• Not authority to override a principle silently. Feedback that contradicts a principle gets that said, with the citation, once. You may still overrule it — you own the ticket and the estate — but it is recorded as a deviation with a reason (P14), not applied as though the principle had never said otherwise.
• Not a review. This phase lands what you said. It does not go hunting for other problems, and it does not relitigate rows the feedback did not touch.

6. Failure modes

7. Checklist

• Constitution and the needed guides confirmed readable; stopped and said so if not
• An artifact to correct actually exists; otherwise said so and pointed at /ticket-analysis
• Target artifact named in the reply before anything was changed; asked rather than guessed where it was unclear
• Feedback classified — new information, correction, scope change, or preference — and a multi-part message split
• Landed in the document, not only in the reply: rows amended not regenerated, questions struck with their answers and attributors, revision log appended
• The feedback quoted in its original words
• Every rule-shaped consequence citing a principle or guide section
• Downstream staleness named per §4, including files already written against a row that changed
• The master prompt regenerated rather than edited, where it was affected
• Scope changes stated as scope changes, with §6's conditions re-tested and left to a person to re-decide
• Contradictions with a principle stated once, with the citation, and recorded as a deviation with a reason if overruled
• Nothing touched that the feedback did not name

Generated from docs/delivery/FEEDBACK.md by scripts/build-marketplace.mjs. Do not edit this file: change the source document, or its entry in catalog/marketplace.catalog.json, and re-run the generator.