reflect-artifacts

name	reflect-artifacts
description	Reflect phase — produce the three success artifacts (a measurable success metric, an instrumentation diff, a check-back ticket draft) without ever reading shipped-app runtime data.

reflect-artifacts

You are in the reflect phase of Coding Mode. Judging whether the shipped feature actually succeeded needs the user's deployed app's runtime telemetry, which a coding harness cannot see — that is a different product and is out of scope (D-CODE-7). What you can do is hand the user artifacts so success is measurable later. Produce all three, only where there is something real:

• Success metric. State one measurable metric for the feature — a number, an event count, a latency/error bound — not "users like it". Name the concrete signal it reads (e.g. a checkout_completed event, the p95 of a handler).
• Instrumentation proposal (a diff). Scaffold the code that emits that signal — an event/log/metric the user wires into their app — and output it as an ordinary edit diff/proposal, the same as any other code work. It is a proposal: the user applies it. Anchor it to the file that would carry it.
• Check-back ticket. File a ticket so success is revisited instead of forgotten. Inside this repo, draft it in the house ticket format — frontmatter (id: AS-NNN continuing the sequence, title, status: ready-to-implement) plus a short body stating the metric to check and when. In any other project, write the equivalent as a markdown check-back note. Draft only: never call cmd/ticket-sync, and never create or mutate a remote issue.

Never read runtime data

You produce artifacts; you do not ingest, fetch, or claim shipped-app runtime telemetry. Do not invent metric values, do not pretend to have read an analytics dashboard, and do not propose that Smith poll a telemetry endpoint. The metric and instrumentation are plans for the user to run, nothing more.

Grounding (required)

Every artifact must anchor to a concrete file, symbol, or ticket. A success metric with no signal to read, or an instrumentation note with no file to land in, teaches nothing. Never write "measure engagement" or "add some metrics".

Good (grounded):

• Success metric: count OrderConfirmed events emitted from internal/checkout/handler.go ConfirmOrder(); target ≥ 95% of started carts within 30 days, file check-back ticket AS-201.
• Instrumentation: add a metrics.Inc("order.confirmed") call in internal/checkout/handler.go ConfirmOrder() — proposed as a diff for review.

Bad (rejected — no anchor / reads runtime data):

• Track engagement and see if it improved.
• Pull last week's conversion numbers from the analytics dashboard.