qfai-implement

/qfai-implement — Implement a business flow

[DRIFT-PROTOCOL:REQUIRED]

Run the entry check of
.qfai/assistant/rule/shared-skill-operating-baseline.md#workflow-run-entry-check-mandatory
first.

Inputs

• <BF-ID>: the business flow, BF-NNNN.
• [EX-ID...]: optional examples of that flow, worked in the order given.
• The flow's stories, acceptance criteria, examples and contracts, from the
  configured paths.specsDir and paths.contractsDir.
• For UI work, root DESIGN.md and the flow's UI contracts. The rendered
  surface is reviewed, not only the source.

Every step follows .qfai/assistant/rule/shared-skill-operating-baseline.md,
.qfai/assistant/rule/shared-skill-delegation-baseline.md and
.qfai/assistant/rule/test-layers.md. Every question to the user follows
.qfai/assistant/rule/shared-skill-operating-baseline.md#user-questions-askuserquestion-protocol.

Steps

<BF-ID> [EX-ID...] runs these steps, in this order:

Acceptance tests come in two phases. implement-scaffold writes them with
empty bodies before the examples are implemented; implement-acceptance
writes their bodies once the system's shape has settled. Unit and component
tests stay test first, in implement-tdd.

The completion gate above therefore leaves the acceptance bodies empty, by
design. They are written by the write-acceptance-tests route, or by
implement-acceptance run alone, and the report says which BF and AC tests
still have an empty body.

Each of these runs alone, instead of that order, when the request is not new
behaviour but a failure, a repair or upkeep:

Read the STEP.md of the current step only, run it, then move to the next.
Each step names the common steps it runs in requires; read those when the
step reaches them.

Inside an npx qfai workflow run, the work order lists the steps to run and
this file adds nothing to it.

Reviewer Gate

After the last step, run one review through common-review-cycle: the code
review, by implementation-reviewer. The review also checks for code
written only to pass a test: no value hard-coded to the test's inputs and no branch written only for the test, and a wrong test or infeasible task raised as a Change Request, not worked around
(.qfai/assistant/rule/test-layers.md#a-passing-test-is-not-the-solution).

The review also checks that the
change adds test files sized like their neighbours, commits no scratch checks,
follows § 4 on unrequested fixes, including its exception for a necessary fix
and reporting requirement, and states any assumption it built on
(.qfai/assistant/rule/test-layers.md#test-suite-sizing,
.agents/rules/minimal-implementation.md § 4).

Completion

The invocation completes on the gate of its last step once
every finding of its one review is fixed or answered. Invoked by name, it runs
npx qfai validate --profile tdd --fail-on error --flow BF-NNNN once, at
completion; when that fresh validate result has no test-obligation EX finding
for this BF, the invocation reports "nothing to do", and reads or writes no
ledger status. Inside a route it runs no validate: the verify stage does.
When the next step needs the user's answer, ask a question listing the next
actions, /qfai-verify recommended, per .agents/rules/user-questions.md § 6.
Completion-only reports ask nothing. Under a no-question mode, list remaining
actions instead.

Default Autopilot Policy

• auto-decide: implementation seam, test selector, and local refactor that
  preserve the active story and contract behavior.
• ask-user: critical product choices.

The BF, EX, and contract sources come from the invocation and configured tree.
If they cannot be resolved, stop at preflight and report the missing source.

project_memory:

• Select EX work from a fresh flow-scoped validator result, one EX at a time.
• BF maps to E2E; AC maps to integration or API; EX maps to every other test.