/auq-grammar

AUQ Grammar: the worked gates to mirror

This file holds the complete worked examples of a good alignment gate - a finding presented to the user, end to end. Two kinds of finding exist, and each has its own worked gate below: the **fork** (a real decision between live alternatives - the brief, the prose, the widget) and the **dead end** (a premise already built or void - a few sentences of fact, then only the story-fate question). Agents that surface a product finding (the alignment check at Step 3, and plan-chunks' fork and triage questions) Read this at gate time and mirror the gate that matches their finding.

It is a model, not a rulebook. The old Step 3 taught the gate as a pile of prose directives, and every one of them lost to the model's instincts. A worked gate carries what a page of rules could not: the length, the air, the voice. The matching matters as much as the mirroring - fork ceremony on a dead end is how a three-sentence fact becomes a six-paragraph novel.

Mirror the shape, not the content

The scenarios below are invented - a fictional checkout form, a fictional saved-cart reminder - chosen because they own nothing in this codebase. The one rule for reading this file: mirror the shape, not the content. Copy how it reads, never what it says:

• **Visible prose.** Every word below is message text the user sees. The reasoning

is never left in thinking with only the widget showing - that failure is the disease this file cures.

• **Short, airy paragraphs.** One idea each, a blank line between them. The lean is

the last line before the widget, in bold - a rushed reader takes the first line of each block plus the bolded lean and still gets the whole gate. Correct content delivered as a wall still fails.

• **Opens from the user's own intent, in plain language.** The first sentence starts

where the user already stands. No term coined during the work reaches them.

The worked gate

_The brief, once, before the first finding:_

> I looked at where this lands. One thing needs your call - I settled the rest > myself (test names, error copy: engineering, not product).

_The finding (it opens on a title naming the problem):_

> **The address check fits three forms - the story covers one.** > > You want the new address check on the checkout form. The same check would fit the > two other forms that take an address - the account page and the shipping-book > editor. > > Those two aren't free, though - each brings its own tests, and the shipping-book > editor has its own submit path entirely, so doing all three roughly doubles the > diff. The account page is the cheap half: it shares checkout's submit path. > > A quick grep puts the address block at three call sites - checkout, account, and > the shipping-book editor. > > **My lean:** do checkout now and split the other two into a follow-up, so this > story still ships this cycle.

_The widget:_

AskUserQuestion:
  header: "1 of 1"
  question: "The new address check would fit two other forms (the account page and the shipping-book editor), but covering them roughly doubles this story. Apply the check to all three forms now, or just checkout?"
  options:
    - label: "Checkout only (Recommended)"
      description: "Ships this cycle; the account page and shipping-book editor become a named follow-up - a clean follow-up, not a corner cut."
    - label: "Checkout plus the account page"
      description: "Covers the two forms that share a submit path; the shipping-book editor stays a follow-up - a solid middle if the account page matters this cycle."
    - label: "All three now"
      description: "Roughly doubles the diff since each form brings its own tests - also solid if you'd rather land it once."

The recommendation is first and carries `(Recommended)`. The label is the decision in plain words - a phrase you could say aloud as your choice. The description opens with the consequence - what picking it does to the story and what happens next - then closes on the honest one-line verdict: the endorsement on the runner-up, the cost stated plainly. The option count follows the argued alternatives - two when only two are real, three when a middle path earned its place; the worked count is never a quota. If you cannot write an honest case for the runner-up, it is not a fork - that is Step 2's filter, not a new one; resolve it yourself and narrate that you did. The harness renders its own `Chat about this` exit under every widget - never author an escape option; every authored option is a real outcome. The evidence was cited once, as a coordinate ("three call sites"), never as a claim of diligence. Every option was already argued in the prose; none is filler invented to round out the list. And the question field stands alone: one or two sentences of the problem, then the ask - answerable by someone who saw nothing above it, on every model. The header chip is the running position counter - `"1 of 2"`, then `"2 of 2"` - never a topic label; it is the only place the user sees how many decisions are coming. This holds for both gates, always; the prose enriches, it is never load-bearing.

The worked dead end

Not every finding is a fork. When the investigation shows the story's premise is already built (or void as written), there is nothing to weigh - the only real question is what the story becomes. Mirror this shape: state the fact in a few sentences, cite the location once, and ask the story-fate question. No brief, no lean, no argued case - a dead end decides itself.

_The finding (same rule - a title, then the fact):_

> **The saved-cart reminder is already built.** > > Checkout builds it and sends it on the schedule the spark describes. I read > the reminder job end to end to confirm. > > The only gap is that no test covers it.

_The widget:_

AskUserQuestion:
  header: "1 of 1"
  question: "The saved-cart reminder this story asks for is already built and running; the only gap is that no test covers it. What