/wakeflow-target-craft

name: wakeflow-target-craft
description: Use when a Wakeflow product target is about to implement or rework its assigned task package.

Wakeflow Target Craft

Load this alongside `wakeflow-target`. `wakeflow-target` governs the immutable dispatch packet, window boundaries, strict `TargetResult` recording, and return transport — the "how do I interact with the state machine". THIS skill governs the "how do I write the code well" so acceptance passes on the first pass instead of looping through rework.

Core stance

The target must leave structured, reproducible REVIEW INPUTS, not a "looks done" claim. Wakeflow can check that required kinds and mappings exist and that exact declared ref/digest tuples are linked; it cannot establish that the referenced contents are true. Every craft practice below exists to give the controller something concrete to inspect and independently rerun before acceptance. Craft prepares an honest review; it does not earn acceptance by itself.

**NO IMPLEMENTATION UNTIL EVERY AUTHORED `acceptanceAnchor` HAS A PLANNED RED TEST OR PROBE; NO COMPLETED RESULT UNTIL EVERY ANCHOR MAPS TO EXACT EVIDENCE REFS.** Violating the letter of this rule is violating its spirit.

• Read the package's `objective`, `requirementRefs`, complete `boundaries`,

`completionExpectations`, `acceptanceAnchors`, and advisory `designIntent` before planning code.

• For each anchor, record `id -> test/probe seam -> expected RED -> expected

GREEN`. Use the exact confirmed claim; do not widen it.

• If an anchor is untestable, conflicts with another authority, or requires

missing facts, return `needs-review`. Never invent a replacement goal.

• A newly authored implementation package without anchors is invalid and must

return `needs-review`. Non-implementation packages (including research, documentation, and Test work) and read-only legacy compatibility packages may legitimately omit them; never create requirement authority yourself.

• A Test dispatch packet may list this Skill because it carries a

`reviewInputContract`. In that case use only the evidence and result-shape guidance here; the packet's `testContract.executionContract` and the target Skill's Test Alignment Gate stay authoritative, and the product implementation practices below do not widen Test's assignment.

The seven practices (each earns a piece of evidence)

1. Plan before you code (self-sequence one package)

Your window receives one immutable TaskPackage for one target task. Its objective may require several implementation steps, but those steps are not separate machine-owned package items. Before touching code, write a short ordered plan: step order, the files each step touches, how each step will be verified, and the acceptance-anchor plan when present. Then execute one step at a time — verify it before starting the next; do not interleave half-done work.

• Earns: an execution-plan note (kind `execution-plan`, optional but welcome).
• The plan also protects you across session compaction: re-read it, the exact

TaskPackage, and the immutable dispatch packet instead of reconstructing intent from memory.

2. Baseline before you start

Run the relevant test suite (and typecheck/lint if cheap) BEFORE your first change, and record the outcome. If the baseline is already red, report it — do not silently adopt pre-existing failures as yours, and never "fix" them outside your declared scope without backfilling a blocker or observation.

• Earns: a baseline record (kind `baseline`: command + outcome).
• Why: many rework loops start as baseline confusion — a reviewer cannot tell

your failures from inherited ones unless you pinned the starting state.

3. Test-first (RED → GREEN)

Before writing implementation for a behavior, write a test that expresses it and watch it FAIL for the right reason. Then write the minimum code to make it pass and watch it GREEN.

• For authored acceptance anchors, the RED must exercise the anchor's declared

probe or a demonstrably equivalent public seam. Report the mapping by anchor id; a general green suite does not prove an unmapped anchor.

• **Bug-fix hard gate:** before editing production code, reproduce the defect

through the real entrypoint named by the task package and capture the RED. Once implementation starts, do not weaken or change that test's entrypoint or behavioral meaning to fit the patch; make the same test GREEN. Do not mock the fact-producing boundary that the task package asks you to verify.

• Fix the first point where the correct fact is lost or changed. Downstream

code may validate or forward that fact, but must not invent it through a fallback, silently drop unknown fields, or parse human-readable messages into structured truth. If the real RED or root cause cannot be established, return `needs-review` instead of editing by guess.

• Produces: a test that covers the change plus ordered, reviewable inputs showing

the same behavior failed before the implementation and passed afterward. When the package says `commitExpectation=commit` and repository policy permits, separate commits may prove that order. For `leave-uncommitted`, preserve it through test output, logs, or evidence files instead of creating commits against the package policy.

• Why the order matters: a test written after the code tends to assert what the

code already does, not what the requirement needs. Test-first pins the requirement.

• One behavior → one test → one implementation. Do not dump many horizontal RED

tests then a single big GREEN.

4. Systematic debugging (defects / when something fails)

Do not guess-and-patch. Build a feedback loop first:

1. Reproduce the exact reported behavior as a check you can run on demand. 2. Form ranked, falsifiable hypotheses. 3. Probe ONE variable at a time until the root cause is established, not assumed. 4. Fix the cause, then add a regression test that fails before and passes after.

• Earns