ultra-builder-pro-cli 5.0.1 → 6.0.0

package/skills/ultra-dev/SKILL.md

@@ -1,265 +0,0 @@
----
-name: ultra-dev
-description: Carry one planned task from a written implementation plan through red-green development to recorded evidence and a task-level review. Use when a task in the ledger is ready to execute, was interrupted partway, or has to be picked up in a fresh session or on another host.
----
-
-# Take one task from plan to recorded evidence
-
-The model owns code reasoning and edits; repository files own the resumable contract.
-
-## Route modes
-
-| Mode | Entry | Observable exit | Next |
-|---|---|---|---|
-| `execute` | Explicit task id or a valid Execution Grant covering one dependency-ready pending task | The named task has current acceptance evidence, final task review, completion context, and a read-back `completed` ledger row | Recommend the next exact `ultra-dev/execute` task or `ultra-test/audit` |
-| `resume` | Explicit task id or a valid Execution Grant covering the unique in-progress task | Existing work is reconciled from Git, context, and Resume Note, then reaches the same completion evidence or a typed stop | Recommend the next exact task, `ultra-test/audit`, or the responsible repair route |
-| `reopen` | Explicit task id or a valid Execution Grant after current evidence invalidates a completed task | The invalidated criteria are refreshed through a new review and the task is completed again, or the remaining gate is named | Recommend the next exact task or `ultra-test/reaudit` |
-
-Follow `../ultra-status/references/route-contract.md`. Show a Route Card before the
-first implementation edit, at material checkpoints or unavailable evidence, and after
-the ledger readback. When context pressure threatens reliable continuation, finish the
-nearest safe write, refresh the Resume Note, and recommend a fresh session rather than
-pretending the task is still making invisible progress.
-
-## Before you start
-
-1. If model-selected, verify the live execution grant in `../ultra-change/references/execution-grant.md` — a current session-local activation or a stably verified durable work-package grant; without either, stop.
-2. Read `../ultra-change/references/change-contract.md` and apply its **Active Change
-   authority resolution** before reading any active `intent.md` or resolving a current
-   `change_id`. Require its one valid authority; otherwise stop with its typed repair.
-   Then read `.ultra/tasks.json`. Without an exact task id in the owner invocation,
-   select only the uniquely current `in_progress` task and read its full
-   `context_file`, especially `## Resume Note`; if none exists, stop and ask
-   the owner to invoke Dev naming one exact task id — a `pending` row is a frontier
-   candidate, not active work, and Hooks will not have injected its acceptance or
-   Resume. An invocation that names one exact task id supplies invocation-local
-   selection authority for this Dev run only. If more than one row claims
-   `in_progress`, do not manufacture a unique current task; use the explicit recovery
-   below or stop with the Hook diagnostic. The ledger is the sole task-status authority;
-   legacy Status or Complexity never overrides it. A `completed` task with a current
-   invalidation observation may be selected only for the explicit reopen below; record
-   and read back that transition before repair.
-3. Read `CONTEXT.md` for vocabulary, and the `.ultra/decisions/` entries the task
-   context names.
-4. Validate `.ultra/north-star.md` with the shipped Research structural sensor. Resolve
-   every listed `FP-*`, `NS-*`, and `HC-*` in the task and active Change against that
-   accepted authority. Compare the active Change's recorded **North Star revision** and
-   **North Star digest** with the accepted file's revision and current Git blob digest.
-   A missing ID, revision mismatch, or digest mismatch is a stale-plan observation: stop
-   before editing and recommend explicit owner invocation of `ultra-change` to reconcile
-   the active Change. Never inherit approval or silently rewrite the trace.
-5. Read the task's acceptance criteria. If you cannot state that acceptance in one
-   sentence, you are not ready to start.
-
-### Activating one named pending task
-
-When the owner invocation names a dependency-ready `pending` task, perform its
-canonical activation before any implementation work: write that row from
-`pending` to `in_progress` in `.ultra/tasks.json` and read the row back before
-the first implementation edit. This one canonical ledger write is what makes
-the named task live for the task-aware Hooks; without it Hooks correctly remain
-task-silent while you edit, because a trusted invocation is visible only to the
-invocation that carried it. The activation adds no selector, activation flag,
-or workflow state — the ledger row is the only authority — and it must respect
-the single-writer boundary: resolve any conflicting `in_progress` rows through
-the recovery below or an owner decision before writing.
-
-### Recover one exact task from an ambiguous ledger
-
-An explicit owner invocation with one exact task id supplies invocation-local selection
-authority for this Dev run even when multiple ledger rows claim `in_progress`. Before
-editing, read that exact canonical ledger row and context, especially its Resume Note,
-then inspect current Git/worktree evidence for the named task. Do not persist a new
-current-task selector, status, or workflow state to manufacture uniqueness. Hooks remain
-task-silent and progress-silent while the ledger is ambiguous.
-
-Only an explicit owner/Plan correction that establishes a conflicting task never started
-may return that row to `pending`. If multiple tasks contain real partial work, keep every
-task with real partial work `in_progress` and preserve each task's bytes. Recover them by
-separate exact task-id owner invocations or obtain owner-authorized Plan reconciliation;
-use a separate worktree when needed to keep their writes isolated. Completing the
-selected task still requires final review, canonical v2 evidence, context publication,
-ledger write, and readback.
-
-When this task starts from an observed error, failing check or unexpected behavior,
-read `references/debugging.md` and establish the earliest incorrect state before editing.
-
-## Definition of done
-
-- All six evidence dimensions carry honest, current observations under the typed v2
-  evidence contract; a real limitation remains a gap rather than becoming a pass.
-- `.ultra/tasks.json` remains the sole task-status authority after write/read-back.
-- The task still names the active `change_id`; historical unfinished work stays out.
-- The context file carries a Completion entry and a rewritten Resume Note.
-- A task-level review runs while the ledger task remains `in_progress`; its blocking
-  findings are resolved or owner-dispositioned as required and affected evidence is
-  refreshed before the model writes `completed` to the ledger.
-
-## Write the implementation plan before the code
-
-Fill in the task context's Implementation section as prose a person can read:
-which modules change, how the interfaces move, which seam the tests will use.
-Confirm that, then write code. Deciding the design while typing implementation
-buries the design decisions in the details.
-
-## Develop through red then green
-
-Follow `../ultra-tdd/SKILL.md`, writing tests only on the seams the plan already
-confirmed, one slice at a time. `ultra-review` owns evidence-backed refactoring when
-observed duplication, coupling, or a boundary defect justifies it; a slice count does
-not make that decision.
-
-## Converge on the task-scoped acceptance set
-
-Development ends when every task-scoped criterion has its required current evidence and
-responsible semantic disposition, not merely when commands pass or the code looks
-finished. Resolve the context's **Change Acceptance IDs** against the active `intent.md`
-for `<change_id>`. For each named row consume its exact `Verification type` and
-`Required evidence`. When one outcome needs more than one authority, split it into
-independent criteria with unique IDs and preserve each authority separately; every row
-has exactly one verification type. Task-local acceptance may add evidence requirements,
-but it does not replace or narrow the Change mapping.
-
-Handle the four verification types without converting one authority into another:
-
-- Execute only `command` observations. Record the exact command, working directory,
-  exit status, retained raw output reference, and its exact SHA-256.
-- For `inspection`, cite the exact source and revision or digest, then refresh the
-  observation after any touched source changes.
-- For `owner-judgment`, preserve the cited owner decision. The owner alone supplies its
-  semantic result; a model statement, validator, score, or command cannot proxy it.
-- For `external-observation`, preserve the provider or system receipt without proxying it
-  with a local command, model claim, or synthetic fixture, and bind its exact bytes by
-  SHA-256.
-
-- Missing `owner-judgment` stops at its named owner gate.
-- Missing `external-observation` stops at its named external or authorization gate.
-- If an inspection exists but its semantic implication is unresolved, stop at the
-  responsible model or owner gate; a structural citation is not an automatic acceptance
-  verdict.
-
-Run one baseline before repairing anything. Track a best-ever evidence set keyed by
-criterion, verification type, and source identity to make progress visible, plus the
-current evidence set used for convergence. Stale or regressed evidence remains history
-but cannot satisfy the current set. Do not infer semantic progress or failure from a
-round count. The loop has three explicit exits:
-
-| Exit | Condition | Action |
-|---|---|---|
-| Converged | Every mapped and task-local criterion has current required evidence of every named type, and the responsible model or owner has made any semantic disposition | Close out below |
-| Stalled | An in-scope repair yields no new or refreshed evidence and no further evidence-producing repair is justified inside the approved task | Stop; report the missing evidence, the attempted repair, and the responsible next gate |
-| Unreachable | Required evidence cannot be observed because an executable, fixture, provider, service, declared environment prerequisite, or required authorization is unavailable | Stop that criterion; report the unavailable prerequisite or gate and its reachable repair path |
-
-A nonzero command exit is an observation, not automatically `Unreachable`; inspect its
-output and repair within scope when justified. None of these exits mechanically decides
-semantic sufficiency, owner acceptance, or external truth.
-
-## Answer the six evidence dimensions
-
-Each has a rule you can check against the work rather than assert:
-
-| Dimension | Answered when |
-|---|---|
-| `tests_written` | This diff adds or changes at least one assertion — touching a test file is not enough |
-| `tests_passed` | The last test run exited zero and covered the files this diff touched |
-| `persistence_real` | On any path that stores data, the test uses real storage or a container |
-| `feature_flags_audit` | No flag on this change's execution path defaults to off, including flags this task did not add but now depends on |
-| `vertical_slice` | One test's execution path runs from the entry point through to persistence |
-| `spec_trace` | The anchor the task's `trace_to` names exists in the specification |
-
-Before task review, retain the actual criterion evidence, raw logs, owner records,
-external receipts, and cited artifacts without inventing another completion record.
-Do not write `evidence.json` before the task's validated final `SUMMARY.json` exists.
-The review packet admits those actual pre-review observations together with the ledger,
-context acceptance, and packet-defined task scope. A structural validator may check
-exact fields, types, digests, paths, and freshness observations. It never supplies an
-acceptance disposition, turns a model claim into command evidence, or decides semantic pass.
-Evidence is a sensor: a gap or legacy v1 record is reported with a migration
-diagnostic, never rewritten as v2 truth.
-
-## When implementation and the specification disagree
-
-This is the one backward edge in the whole workflow. Classify before touching the
-specification, and classify by outcome rather than reason: does every commitment
-the specification already made still hold afterwards? If even one no longer holds
-it is a REDUCTION — stop and ask the owner, however good the argument. Log the
-classification in the context file's Change Log.
-
-## Close out
-
-Keep the ledger row `in_progress` while running task review through
-`../ultra-review/SKILL.md`. Build its immutable packet from the ledger, task context,
-packet-defined task scope, and actual pre-review evidence; the final v2 record is not an
-admission prerequisite. Route only the exact current P0/P1 findings (or a P2 the owner
-explicitly promoted) as one in-scope repair set, followed by one affected-lens delta
-review per repair set inside the active review budget — an exact current owner grant
-overrides the versioned product default of one initial review plus at most two
-P0/P1 delta reviews per package. When another `REQUEST_CHANGES` would exceed the
-active budget, return to the owner checkpoint with the exact blocking set instead of
-an automatic repair; the same root surviving three failed fixes stops point-patching
-and reports an architecture problem. Budget exhaustion stops execution at `owner checkpoint` /
-`budget_exhausted` and keeps the ledger row `in_progress`.
-It never yields `APPROVE`, `REQUEST_CHANGES`, `INCOMPLETE`, pass, fail, accept, or
-abandon. If a repair changes implementation or evidence in review scope, use a new
-immutable packet and validated review summary before closeout rather than rebinding the
-old review. Worker Packet v1 and its summary do not bind a task worktree digest.
-
-After the final validated `SUMMARY.json`, write one canonical `ultra-task-evidence-v2` record only after completing the raw-receipt binding below.
-When the task's owner-designated review mode is external manual, the final review
-product is instead the external reviewer's real receipt, bound through the
-`review_mode: "external-manual"` branch of
-`../ultra-plan/references/task-evidence-v2.md`: publish that receipt under
-`.ultra/evidence/<task-id>/`, record its exact stable-byte SHA-256, and verify it
-with the sensor's `--verify-external-receipt` mode instead of inventing a strict
-session. Never fabricate one branch's artifacts to satisfy the other's shape.
-The `subject` is an independently captured completion-snapshot freshness observation.
-Before writing `evidence.json`, resolve every
-command and external-observation `raw_evidence_ref` below the real repository root and
-take bounded stable repository-contained bytes from an ordinary regular non-symlink file
-opened nonblocking and no-follow. Reject a missing, escaped, symlinked, special,
-oversized, or replaced file; otherwise compute `raw_evidence_sha256` from that one byte
-snapshot. Publish that canonical record at `.ultra/evidence/<task-id>/evidence.json`,
-read back the stable record and each raw ref,
-and require the same ref bytes and digest before continuing.
-Follow `../ultra-plan/references/task-evidence-v2.md`: `task_review` separately binds the retained strict summary; record one typed acceptance entry per criterion, all
-six dimensions, the exact Execution Packet and review identities, blocking-finding
-dispositions, evidence refresh refs, artifacts, limitations, and retention without
-claiming that the review summary proves `subject.worktree_digest`. Read the record back, then update context
-`## Task Review`, Completion, and `## Resume Note`; the context has no second status.
-Only after those facts are durable may the primary model write `completed` to the
-ledger and read the row back. When the task's work package sits under an
-ACK-ready primary transfer whose newest terminal receipt is a completed v2
-RESULT, this sequence is that contract's prescribed closeout: publish the
-handoff's `CLOSEOUT.json` beside the frozen RESULT — citing the review receipt,
-the closeout-start/end observations, and any recorded owner-authorized
-continuation — instead of refreshing the RESULT or opening a new handoff; the
-closeout starts no review and no repair round
-(`../ultra-change/references/primary-transfer.md`).
-
-If later work invalidates a completed task's criterion evidence, Dev performs an
-explicit reopen. A reopen changes the ledger row from `completed` to `in_progress`;
-Dev must never silently demote the row. Before that write, record the affected criterion IDs and reason in both the context Change Log and Resume Note, preserve the prior review as
-historical evidence, then write and read back the ledger transition. Refresh the named
-evidence, run task review for the new snapshot, and repeat this closeout sequence.
-
-Report the changed paths, the seam, the exact checks run, the review result, the
-evidence gaps and the residual risk. Recommend the next capability from what the files
-now say. Continue only when its exact mode and effects remain inside the valid grant and
-after showing the transition Route Card; otherwise do not invoke it.
-
-## When the owner decides
-
-The owner decides any REDUCTION and each external effect separately. At most one
-authorized local task commit happens here; push, tag, publish and deploy need separate
-authority. An interruption leaves the worktree as-is and names it in the Resume Note.
-
-## References
-
-- `../ultra-change/references/change-contract.md` — canonical Active Change authority resolution.
-- `../ultra-tdd/SKILL.md` — read before the first test, for the seam and mock boundary.
-- `../ultra-think/references/autonomy-boundary.md` — read when spec and code disagree.
-- `../ultra-review/SKILL.md` — read when implementation evidence is ready for review.
-- `../ultra-change/references/execution-grant.md` — read only for grant-activated continuation.
-- `../ultra-status/references/route-contract.md` — owner-visible route, checkpoint, and recovery output.
-- `../ultra-plan/references/task-evidence-v2.md` — canonical evidence, disposition, and task-review shape.
-- `references/debugging.md` — read for a reproduced failure before selecting a repair.

package/skills/ultra-dev/references/debugging.md

@@ -1,22 +0,0 @@
-# Evidence-first debugging
-
-Use this procedure for an observed error, failed check, or unexpected behavior. Diagnose
-before editing and work backward from the symptom to the earliest state that violates
-the accepted contract.
-
-1. Capture the complete symptom and reproduce it with the smallest exact command or
-   action. A different checkout or nearby passing test is not reproduction.
-2. Inspect the relevant diff, configuration, dependency, caller, side effect, and
-   runtime boundary.
-3. Form one falsifiable root-cause hypothesis and choose the smallest observation that
-   distinguishes it from alternatives.
-4. Test the hypothesis without broad refactoring. Record evidence that accepts or
-   rejects it in the active task context `## Change Log`.
-5. Write the failing regression on the public seam, then apply the smallest root-cause
-   repair through `ultra-tdd`.
-6. Rerun the exact reproduction and affected verification. Record residual uncertainty
-   and the recovery path in task evidence.
-
-After three distinct repair attempts reveal different underlying failures, stop
-patching. Treat the shared boundary as the next diagnostic target and report the
-evidence; do not disguise architectural uncertainty with another local fix.

package/skills/ultra-domain-modeling/SKILL.md

@@ -1,79 +0,0 @@
----
-name: ultra-domain-modeling
-description: Settle the project's vocabulary into CONTEXT.md — one opinionated definition per term, the rejected wordings, the relationships between terms, and the ambiguities already resolved. Use when another skill changes the shared language, meaning a term gets coined, two words compete for one concept, or one word turns out to mean two things.
----
-
-# Keep one file that fixes what each domain word means
-
-This is how implementation reaches the earlier documents — not by better
-retrieval, but by needing less of it. `CONTEXT.md` is a compressor, not an index.
-What implementation lacks is rarely the content of the product specification; it
-is the vocabulary, so that trace anchors, variable names, function names, and
-test names all line up. It serves Goal 4, Cognitive Coherence.
-
-## Before you start
-
-1. Read `CONTEXT.md` at the repository root if it exists. Every skill reads it
-   for vocabulary; this one is for the moments that *change* it.
-2. Read the owner's current wording verbatim — their words are the raw material.
-3. Check the code for the same concept: type names, table names, function names.
-
-## Definition of done
-
-- Every term settled in this exchange is in the file, written the moment it was
-  settled rather than batched at the end.
-- Each entry defines what the term *is* in one or two sentences, and lists the
-  wordings that lost.
-- The file still holds vocabulary only, carrying no implementation detail.
-
-## The file
-
-Create it at the repository root the first time a term is actually settled, not
-before. This is the whole format:
-
-```markdown
-# {project name}
-
-{One or two sentences: what this context is and why it exists.}
-
-## Language
-
-**Order**:
-{One or two sentences. Define what it is, not what it does.}
-_Avoid_: Purchase, Transaction
-
-## Relationships
-
-- One **Issue tracker** holds many **Issue**
-
-## Flagged ambiguities
-
-- "backlog" meant both the tool and the set of work — settled as **Issue tracker**
-```
-
-## Sharpen the language as it is spoken
-
-When several words compete for one concept, pick the best one and send the rest
-to `_Avoid_`. Keep only terms this project gives specific meaning to; general
-programming concepts stay out.
-
-- Name the conflict the moment it appears: the vocabulary defines cancellation
-  as one thing, and this sentence uses it as another — which one is meant?
-- Sharpen a vague word on the spot: "account" is either Customer or User.
-- Pressure-test a boundary with a concrete scenario.
-- Cross-check against the code: it cancels a whole Order, yet the description
-  allows cancelling part of one — which is true?
-
-## When the owner decides
-
-A term's meaning is the owner's to settle; you supply the candidates, the
-conflict you found, and your recommendation. Where the answer is a genuine
-trade-off, hard to reverse, and would look strange to a reader without the
-background, it belongs in a decision record instead of a vocabulary entry. All
-three have to hold, or `decisions/` fills with a log. Create that directory on
-the first record that qualifies.
-
-## References
-
-- `../ultra-think/references/autonomy-boundary.md` — read when renaming a term an
-  accepted specification already uses; that renaming is a C5 boundary.

package/skills/ultra-grilling/SKILL.md

@@ -1,121 +0,0 @@
----
-name: ultra-grilling
-description: Turn caller-named missing owner decisions into confirmed answers, one question per turn and each carrying a recommendation. Use when Init needs a raw brief field, Research needs an owner decision, or Change and Plan need an explicit boundary or acceptance criterion.
----
-
-# Turn a vague ask into a decision list the owner has explicitly confirmed
-
-No-one knows exactly what they want at the start. This prevents the misalignment
-that surfaces at the end, when both sides believed they had agreed and the
-finished work proves otherwise. It serves Goal 1, Intent Fidelity.
-
-## Before you start
-
-1. Reread what the owner said in the current request, verbatim.
-2. Read `.ultra/project-brief.md`, `.ultra/north-star.md`, and `CONTEXT.md` where they
-   exist. Raw intake is reusable input; accepted wording must not be re-asked.
-3. Look up every fact you can reach on your own: repository files, Git history,
-   installed dependencies, tool output.
-
-Facts are yours to find, decisions are the owner's to make. A question they could
-have answered by reading the repository spends the one input only they can give.
-
-## Definition of done
-
-- Every field the caller named as required is either answered in the owner's own
-  words or explicitly deferred with the reason recorded. "Every branch of the
-  tree" is not something you can check against a file; the caller's field list is.
-- The reframe below was put to the owner and either confirmed or corrected. It is
-  never skipped because the original wording sounded clear.
-- Each answer carries the owner's confirmation, rather than something that
-  sounded like agreement.
-- The caller owns the final artifact and receives a decision list it can write: one
-  line per decision, each with the options rejected and why.
-
-## Extract, reframe, then ask
-
-**Extract.** Restate what the owner already told you and ask them to confirm the
-restatement. Ask only about what is genuinely missing. Re-asking something they
-answered teaches them that answering does not stick.
-
-**Reframe.** The owner describes a *form* when they want a *role*. Say what you
-believe they actually want, name the gap against their wording, and end on a
-question:
-
-> You said a daily briefing app. What you described is a personal chief of staff
-> — the briefing is one of its outputs, not the thing itself. Have I got that
-> right?
-
-This is what separates the loop from a questionnaire. A form accepted at face
-value yields a specification that is internally consistent and builds the wrong
-product. Offer the reframe, never assert it, and treat a correction as the better
-outcome — "no, it really is just the briefing" is a constraint you did not have a
-minute ago. Read `references/reframing.md` for when it applies and how it fails.
-
-**Then ask** only what the confirmed reframe leaves open; the caller sets the semantic depth, so Init stops at the raw outline and leaves baseline questions to Research.
-
-## One question per turn
-
-Ask through the host's native question surface, one unresolved choice at a time,
-and wait for the answer. Several questions at once gets the easy one answered and
-the load-bearing one skipped.
-
-Every question carries your recommended answer and what would change it. A
-question without a recommendation hands your own work back to the owner.
-
-Order questions so that answering one unlocks the next. Ask the framing questions
-before the detail questions — a detail settled inside the wrong frame has to be
-asked again.
-
-**Framing questions** come first, selecting only prompts from
-`references/reframing.md` that can change the current frame. They refuse the owner's
-framing on purpose, which is how they surface what the request left out. Stop once the
-owner confirms the frame or further prompts cannot distinguish a materially different
-build; a question count never decides that.
-
-**Detail questions** fill in the confirmed frame:
-
-- What happens when this goes wrong, and how would we find out?
-- Which of these options is cheaper to reverse?
-- What are we deliberately not doing?
-- What does done look like, concretely enough to check?
-
-An answer counts once it is specific enough to **rule something out**. "It should
-be fast" rules nothing out; "the list renders before they finish typing" does.
-When an answer rules nothing out, ask what would have to be true for the owner to
-*reject* a candidate solution.
-
-Skip what you can derive, what does not change the work, and what they already
-settled.
-
-## When the owner decides
-
-This whole skill is owner-facing, so the boundary is narrow: hold the loop open
-until each decision is confirmed explicitly, and start no implementation on an
-inferred consensus.
-
-## How the loop ends
-
-Every ending hands back the same result: decisions written one per line, each with
-the options rejected and the reason they lost. The caller alone chooses the canonical
-destination; Grilling never promotes an answer into project authority by itself.
-
-- **Resolved** — every required field answered or explicitly deferred.
-- **Stalled** — the evidence shows that another in-scope question cannot produce a new
-  decision without unavailable owner input or a newly framed choice. Hand back the open
-  fields, the attempted distinctions, and what each one blocks; do not infer this from
-  a turn count.
-- **Unavailable** — the host cannot ask, or the owner stopped answering. Hand back
-  the last confirmed state, every unanswered field named.
-
-A loop with no exit traps the owner as much as you: re-asking what they cannot
-currently answer costs more than deferring it. Deferral is a recorded outcome,
-not a failure. Where the host has no structured question surface, ask one plain
-question per turn instead.
-
-## References
-
-- `references/reframing.md` — read before the first question: when to reframe,
-  how it fails, the framing prompts, and what counts as an answer.
-- `../ultra-think/references/autonomy-boundary.md` — read when an answer removes
-  something the specification already promised, or otherwise crosses C5.

package/skills/ultra-grilling/references/reframing.md

@@ -1,76 +0,0 @@
-# Reframing: recovering the role from the form
-
-An owner fluent in their own domain still describes a **form** when what they
-want is a **role**. They are not being vague; they are naming the nearest thing
-they can picture. Taken at face value, that name produces a specification that is
-internally consistent and builds the wrong product.
-
-## When to reframe
-
-Most first asks qualify. Any one of these is enough:
-
-- the request names an artifact — an app, a dashboard, a bot, a script — rather
-  than an outcome;
-- the request names a solution whose problem has not been stated;
-- the request would be satisfied by something far smaller, or is impossible as
-  worded;
-- two readings of the request would lead to materially different builds;
-- the request describes what a competitor has, rather than what the owner needs.
-
-## How to put it
-
-State what you believe they want, name the gap against the words they used, and
-end on a question:
-
-> You said a daily briefing app. What you described is a personal chief of staff
-> — the briefing is one of its outputs, not the thing itself. Have I got that
-> right?
-
-Rules that keep this honest:
-
-- **One reframe at a time.** Two competing reinterpretations in one turn is a
-  quiz, and the owner will pick the one that sounds more flattering.
-- **Offer it, never assert it.** A reframe is a hypothesis about their intent,
-  and they are the only authority on it.
-- **A correction is the better outcome.** "No, it really is just the briefing" is
-  a constraint you did not have a minute ago. Record it as a decision.
-- **Never reframe toward what is easier to build.** If your reinterpretation
-  happens to shrink the work, say that out loud and let the owner weigh it.
-- **Stop when the owner rejects the proposed role and confirms their original frame.**
-  Do not keep producing cosmetic reinterpretations. If a materially different reading
-  later becomes evidenced, present that new distinction rather than counting prior
-  attempts.
-
-## Framing questions
-
-These refuse the owner's framing on purpose, which is how they surface what the
-request left out. Ask only the prompts that can distinguish a materially different
-build, and stop when the owner confirms the frame or the remaining prompts cannot
-change it.
-
-| Question | What it recovers |
-|---|---|
-| What do you do today, without this? | The real job, with the proposed form stripped off |
-| What would make you say this was a waste of effort? | Success via its negative — people picture failure far more concretely than they picture success |
-| What must never happen, even if it would work better? | The hard constraints they were never going to volunteer |
-| If it could only do one thing and you would still use it, which? | Core against periphery, before scope has a chance to spread |
-| Whose situation gets worse when this exists? | Stakeholders, and the constraints attached to them |
-
-Two of these are worth their place for a specific reason. Asking for success
-directly gets an aspiration; asking what would make it a waste gets a threshold.
-Asking who is made worse off surfaces the constraints an owner never thinks to
-state, because to them they are simply how the world is.
-
-## What counts as an answer
-
-An answer counts once it is specific enough to **rule something out**.
-
-| Not yet an answer | An answer |
-|---|---|
-| "It should be fast" | "The list renders before they finish typing" |
-| "It should be secure" | "A support agent must never see a full card number" |
-| "Keep costs reasonable" | "Under fifty dollars a month in API spend" |
-
-When an answer rules nothing out, do not re-ask the same question louder. Ask
-what would have to be true for the owner to **reject** a candidate solution — the
-rejection criterion is the constraint, stated from the other side.