wakeflow-target · diff
git:20260803.ec07199 to git:20260824.12503b6
118 added, 193 removed. Audit A to A.
---
name: wakeflow-target
- description: Use when a target Codex window receives a Wakeflow Delivery Loop direct-thread delivery, executes only its assigned dispatch packet, reports a TargetResultEnvelope, or enforces target-window boundaries without claim / finish / chain-next state.
+ description: Use when a target Codex window receives an exact Wakeflow v3 delivery, executes only its assigned TaskPackage, records a transport-bound TargetResult, or performs an authorized Controller return without taking controller authority.
---
# Wakeflow Target
- Use this skill only inside a target-window automation wakeup. Workspace and
- target-repository `AGENTS.md` files remain hard boundaries. The dispatch prompt
- states the current objective and reading order; the referenced JSON task
- package owns complete task context; anchored requirement documents own original
- goal/background; this skill and any listed craft/Test skills own execution
- procedure.
+ Use this skill only inside the target window named by the current delivery.
+ Workspace and repository `AGENTS.md` files remain hard boundaries. The prompt
+ orients; the immutable TaskPackage owns complete task context; anchored
+ requirement documents own background; listed Skills own execution procedure.
## Prompt Shape
- Target wakeups should be task-first and compact:
+ Target wakeups stay task-first and compact:
```text
Continue current window task: <currentWindow> / <taskId>.
Current objective (the task package is authoritative):
- <one-line objective>
Completion focus (up to two; full criteria are in the task package):
- <bounded observable result>
- <optional second bounded observable result>
- - Priority context: <the highest-priority confirmed fact>
- - Critical boundary [forbidden|outOfScope|inScope]: <the highest-priority boundary>
+ - Priority context: <highest-priority confirmed fact>
+ - Critical boundary [forbidden|outOfScope|inScope]: <highest-priority boundary>
Key acceptance anchors (full probes and expectations are in the task package):
- <anchor id>: <claim>
Read before execution, in order:
- Task package (complete task context): <absolute package path>
- - Requirement background entry (full anchors are in the task package) [goal]: <document#section>
+ - Requirement background entry: <document#section>
- Workspace instructions (only when distinct from repository instructions): <workspace>/AGENTS.md
- Repository instructions: <repository>/AGENTS.md
- Current state root: <absolute state-root path>
Required execution Skills (execution-process authority):
- skills/wakeflow-target/SKILL.md
- - <other package-selected skill, when required>
+ - <other package-selected Skill>
Identity (full boundaries are in the task package):
- Current responsibility window: <window>
- Only working repository: <absolute repository path>
- Before coding: map every acceptanceAnchor in the task package to a RED test or
- probe; return needs-review instead of inventing a requirement when an anchor
- cannot be tested.
+ Before coding: map every `acceptanceAnchors` entry to a RED test or probe; return
+ needs-review instead of inventing a requirement when an anchor cannot be tested.
Return requirement:
- - Execute only this task package. Return a TargetResultEnvelope with target-authored
- review inputs and reproducible validation details through this Skill. Wakeflow
- checks their structure and locatability only; a target result is not controller acceptance.
- - Test execution contract: <package path>#testExecution
+ - Execute only this TaskPackage and record a TargetResult with reproducible,
+ target-authored review inputs. It is never controller acceptance.
+ - Test execution contract: <dispatch packet path>#testContract.executionContract
Dispatch record (routing and trace only):
- taskId: <taskId>
- taskPackageId: <package>
- stateRoot: <path>
- stateRevision: <revision>
- dispatchGroup: <group>
```
- Do not expect the prompt to repeat command manuals or the whole requirement.
- It repeats at most two completion expectations, the highest-priority
- `contextSummary` entry, one critical boundary, and four acceptance-anchor
- ids/claims for immediate orientation. Workspace instructions, anchors, the RED
- instruction, and the Test contract are conditional.
- It does not repeat remaining context, complete boundary lists, commit policy,
- full probes/expectations, or every completion/requirement entry.
- Read the package first, then its ordered requirement anchors, then execute
- through the listed Skills. Fields such as `controllerWindow`, `returnPolicy`,
- `taskPackageId`, and `stateRevision` remain authoritative in machine state.
- The prompt's task/package/revision fields are navigation and freshness anchors,
- not a second copy of task content. `stateRevision` identifies the dispatch
- snapshot in the packet/envelope; the later delivery-sent event may legitimately
- advance the live state root.
+ The prompt may omit conditional lines. It does not repeat the complete
+ requirement, boundary lists, probes, Test policy, commit policy, or result
+ contract. Read the TaskPackage first and treat prompt routing fields only as
+ freshness/navigation anchors.
## Target Flow
- 1. Consume the delivery envelope.
- - Direct-thread delivery proves only that a prompt was delivered.
- - Confirm the responsibility window, `taskId`, `stateRoot`, and optional
- `dispatchGroup`.
- - Read the workspace and target repository `AGENTS.md` files listed in the
- prompt and declare the current window and repository responsibility.
- 2. Read the assigned task.
- - Read the task package at the exact prompt path, then its ordered
- `requirementRefs`, then every Skill listed by the delivery prompt /
- `taskBriefing`. Those Skills are derived from work type, evidence/anchor
- needs, and the Test contract; they are not ordinary task-package prose.
- Do not substitute a progress summary for the package or treat background
- documents as an execution procedure.
- - Execute only the task assigned to this target window.
- - Do not claim another target, Test role, or controller role.
- - If the prompt lists the craft skill, or the task package carries an
- `evidenceContract` or `acceptanceAnchors`, ALSO load
- `skills/wakeflow-target-craft/SKILL.md` before writing code. When anchors
- exist, map every anchor id to a RED test/probe before implementation; an
- untestable anchor is `needs-review`, never permission to invent a
- replacement requirement.
- - When the task package carries `testExecution`, apply the Test alignment
- gate below before writing a plan or running a command.
- 3. Work inside repository boundaries.
- - Change only files permitted by the task and repository rules.
- - Keep commits, tests, and evidence scoped to the owning repository.
- - If another repository must change first, stop and backfill a blocker.
- 4. Produce controller review inputs.
- - Include changed files, commands, test output, commit hash when available,
- logs, runtime JSON, report paths, screenshots, or other reviewable inputs.
- - Prose alone is not enough for completion.
- 5. Record a `TargetResultEnvelope`.
- - Use the Wakeflow MCP `wakeflow_record_target_result` tool for the result
- envelope. This is one narrow file/state action: it records target-authored review inputs
- only, and it does not review, accept, dispatch, send, or return. Pass the
- `dispatchGroup` from your delivery prompt: a late result from a superseded
- round then leaves the in-flight round's window lock alone.
- - Read the tool response's `deliveryContext` / `controllerReturn` fields.
- `returnRoute` and `returnPolicy` live in the local delivery envelope, not
- the controller state root. Do not decide "no callback" by searching only
- `wakeflow-state.json`.
- - Report `completed`, `blocked`, or `needs-review` honestly.
- - Include a non-empty summary, changed repositories, commits, and
- `commitDisposition` (`committed`, `left-uncommitted`, or `no-changes`) so
- the controller can compare the result with the package's
- `commitExpectation`.
- - For a completed implementation package, add exactly one
- `craftEvidence` entry per authored anchor:
- `{kind:"acceptance-anchor", anchorId, red, green, ref}`.
- - Include evidence references and residual risks.
- 6. Return to the controller only when allowed.
- - Target-to-target next-hop delivery is forbidden by default.
- - If `wakeflow_record_target_result` reports `controllerReturn.required=true`
- or the local delivery envelope has `returnRoute=controller`, use
- `wakeflow_review_pack` scoped to YOUR OWN dispatch group as a sanctioned
- read-only self-check (reviewing other groups or deciding accept/rework stays
- with the controller). Always pass `stateRoot`; do not reuse a group-only
- pack or cache an older `controllerReturnDelivery.status` / `returnFile`.
- Follow the pack's current-version `callbackPlan`, not the dispatch group's
- historical send status:
- - If a unit has `buildAllowed=true` or `controllerReturnNextStep` is
- `build-controller-return`, use `wakeflow_prepare_delivery` with
- `direction=controller-return` to build one envelope for the stored
- `controllerWindow`.
- - If a unit has `hostSendRequired=true` or `controllerReturnNextStep` is
- `send-controller-return-and-record-delivery`, send the already-built
- envelope and record it; do not prepare a duplicate.
- - If a unit has `controllerReachUnconfirmed=true` or
- `controllerReturnNextStep` is `controller-return-sent-unconfirmed`, end
- the transport turn without resending and report that controller
- visibility is unconfirmed; this is not callback success.
- - Stop only when the current unit has `controllerAlreadyReached=true` or
- `controllerReturnNextStep` is `controller-return-already-sent`.
- A delivery for an older `resultVersionKey` never satisfies the current
- result revision. These transport signals are INDEPENDENT of review-input quality. Do
- NOT withhold the callback because `missingEvidenceRefs` is non-empty or
- `nextAction` says `fix-missing-review-input-refs-before-controller-verdict`:
- review-input completeness is the controller's POST-wake starting point, and the controller cannot act on it until
- you wake it.
- - If the target task references a delivery id but the local delivery envelope
- cannot be found, stop and report that missing local envelope; do not assume
- no callback is needed.
- - Complete the real host send plus one bounded read-only observation with
- the same host thread tool used for controller-to-target delivery. The prepared envelope intentionally
- redacts the thread handle: read its `targetThread.threadRegistryFile`
- under `.wakeflow-local/wakeflow-delivery/`, load the registered `threadId`,
- call `send_message_to_thread`, then use `read_thread` only for bounded
- observation of the exact new turn. Inspect the host tool's returned value:
- an error or error-looking string such as `Invalid URL` is
- `rejected-before-send`, not acceptance. Never classify transport from the
- JavaScript return type or from the absence of a thrown exception. Use `wakeflow_record_delivery` to
- record the delivery run. Do not guess thread object keys or expose the id
- in tracked files.
- After explicit host acceptance, wait 1200 ms (hard cap five seconds) and
- call `read_thread` exactly once. If the new turn is not visible, record
- `readbackStatus=pending|unavailable` and `readbackAttempts=1` (or `0` only
- when no read was possible). That record is `sent-unconfirmed`, not
- controller reachability; never read again or resend automatically.
- Controller-return does not acquire a target work lease.
- - Do not stop after writing the target result when controller return is
- allowed. The closeout steps stay separate: record target result, review
- readiness, prepare controller-return envelope, send with the host thread
- tool, then record delivery facts. Do not replace them with one combined
- target-window tool or duplicate the target result into another local result
- store.
+ 1. Confirm identity and authority.
+ - Arrival proves only transport, not authorization beyond the exact
+ envelope/TaskPackage.
+ - Confirm the typed target window, task, demand, dispatch group, packet, and
+ current delivery lineage. A title, cwd, or prompt assertion is not identity.
+ - Read the listed workspace/repository `AGENTS.md` files and declare the one
+ repository responsibility before changing anything.
+ 2. Read the complete task.
+ - Read the exact TaskPackage, ordered requirement refs, and every listed
+ execution Skill.
+ - Follow the packet's ordered `taskBriefing.requiredSkills`. Non-Test packets
+ load `skills/wakeflow-target-craft/SKILL.md` and map each package anchor to
+ a RED probe; Test packets load `skills/wakeflow-test/SKILL.md`.
+ - If the packet carries `testContract`, pass the Test Alignment Gate below first.
+ 3. Execute within the one assigned repository.
+ - Do not claim another target, Test role, controller role, or repository.
+ - If another repository or a product decision is required, stop and return a
+ concrete blocker instead of widening scope.
+ 4. Produce reviewable inputs.
+ - Name changed files, diffs/commits, commands and outcomes, logs, reports,
+ runtime observations, screenshots, and residual risks as applicable.
+ - Prose alone is not completion evidence.
+ 5. Import the TargetResult.
+ - Call `wakeflow_record_target_result` with `operation: "import"`, the typed
+ `demandId`, and `request:{artifact,transition}`. The transition is exactly
+ `{eventId,createdAt,reason,decisionSummary}`. Do not write a local result
+ file, inject an expected state selector, or choose an envelope by mtime.
+ - The owner accepts only the strict current group → packet → target envelope
+ → accepted/ambiguous run → settlement lineage. A first result for a new
+ envelope is a new round, not a correction. Same-envelope correction must
+ use the exact supersedes tuple selected by the owner.
+ - Report `outcome` as `completed`, `blocked`, or `needs-review` honestly,
+ with a non-empty summary, exact `repositoryChanges`, `evidenceLocators`,
+ verification outcomes, risks, and `craftMapping`.
+ 6. Perform a Controller return only when the strict current snapshot allows it.
+ - Call `wakeflow_review_pack operation=group` for this demand/group. It is a
+ read-only snapshot, not permission to inspect another group or decide
+ acceptance.
+ - When the current return unit is eligible, call
+ `wakeflow_prepare_delivery operation=controller-preview`, inspect the exact
+ result-set/review/binding digests, then call `controller-apply` with the
+ confirmed plan. Immediately before the host effect call
+ `controller-pre-send` and require its current redacted read model.
+ - Send the stored prompt through the Codex host tool under its operation
+ fence and make at most one bounded readback. Do not read a raw handle from
+ `.wakeflow-local`; the host seam resolves it from the typed binding.
+ - Record the observed fact with `wakeflow_record_delivery
+ operation=controller-outcome`. This call is not the effect fence and a
+ Controller return never acquires the target work lease.
+ - An accepted, ambiguous, or sent-unconfirmed current result set is
+ deduplicated and must not be resent. Rejected-before-send requires an
+ explicit later rearm authority; do not invent retry state.
+ Target-to-target next-hop delivery is forbidden. Result import, review
+ inspection, Controller-return preparation, host effect, and outcome recording
+ remain separate operations.
+
## Test Alignment Gate
- **TEST MUST NOT INVENT A TEST GOAL, TEST GATE, OR TEST METHOD OUTSIDE THE CONFIRMED REQUIREMENT GOAL AND APPROVED TEST PLAN.** Violating the letter of this rule is violating its spirit.
+ **TEST MUST NOT INVENT A TEST GOAL, GATE, OR METHOD OUTSIDE THE CONFIRMED
+ REQUIREMENT GOAL AND APPROVED TEST PLAN.**
- For a package with `testExecution`:
+ For a dispatch packet with `testContract.executionContract`:
- 1. Do not reopen, replace, or assume ownership of total control's prior
- validation. Explore only the assigned environment boundary for hidden
- defects.
- 2. Treat `requirementGoal` and `approvedPlan` as authority, not suggestions.
- 3. Before execution, map every operational plan step to one `approvedPlan`
- item and state how it serves `requirementGoal`.
- 4. Use only skills listed in `allowedSkills`. In particular,
- `progressive-chain-validation` is forbidden unless that exact id is listed;
- a long workflow does not authorize PCV by itself.
- 5. Follow `mode` and `setupPolicy`. Do not rebuild, restart, or replace the
- environment unless the package says `mode=restart` and records a
- controller-approved `restartReason`.
- 6. If a useful step, skill, goal, gate, or restart is unmapped or unauthorized,
- stop before executing it and return `blocked`/`needs-review` as a change
- request to the controller. Do not run it first and justify it afterward.
+ 1. Explore only the assigned real-environment/diagnostic boundary; do not
+ assume ownership of the controller's earlier validation.
+ 2. Treat `requirementGoal` and `approvedPlan` as authority.
+ 3. Map every operational step to one approved-plan item before execution.
+ 4. Use only `allowedSkills`; unlisted methods, including PCV, are forbidden.
+ 5. Follow the exact mode/setup policy. Restart/rebuild only when explicitly
+ authorized with its reason.
+ 6. Return an unmapped or unavailable step as blocked/needs-review before
+ executing it.
- The completed result must map every approved item exactly once with
- `{kind:"test-step", planIndex, step, ref}` in `craftEvidence`; `step` must be
- the approvedPlan text at that index. A missing, duplicate, or unknown index is
- not a completed Test result. The controller, not Test, decides whether a
- proposed change becomes a revised Test card/package.
+ A completed Test result maps each approved item exactly once with
+ `{kind:"test-step", planIndex, step, ref}`. The controller alone decides
+ whether evidence changes the verdict or Test plan.
## Stop Conditions
- Stop and return a blocker when:
-
- - The window identity or target repository cannot be confirmed.
- - The state root, task id, or dispatch group is missing or inconsistent.
- - Required referenced input documents are missing.
- - The task asks this target to change another repository without authorization.
- - The task is only a prompt, not a state-root or task-package assignment.
- - Validation fails and the next repair would change scope or repository
- responsibility.
- - A Test delivery appears in a non-Test window without explicit authorization.
+ Stop and return a blocker when identity/lineage is missing or inconsistent,
+ required inputs are unavailable, the task crosses repository/role scope, an
+ acceptance anchor cannot be tested, a Test method is unapproved, or the next
+ repair would change a product decision. Never treat a bare prompt, stale
+ envelope, old result, or legacy local runtime as current authority.
- ## Result Envelope Contract
+ ## Result Contract
- For the MCP call, pass the task as `taskId`; the persisted artifact records it
- as `targetTaskId`. Every `completed` result must include the following complete
- contract. `blocked` or `needs-review` may carry partial review inputs, but
- must still identify the task/group/state and provide a concrete blocker
- summary:
+ Every result is a strict `artifactKind:"wakeflow-target-result"` record. It
+ binds the immutable demand, `targetTaskId`, exact
+ `taskPackage:{taskPackageId,ref,digest}`, `assignment`,
+ `observedState:{revision,eventId,eventDigest}`, and exact
+ `transport:{group:{id,ref,digest},envelope:{id,ref,digest}}`. It also includes:
- - `targetWindow`
- - `targetTaskId`
- - `dispatchGroup`
- - `stateRoot`
- - status and summary
- - changed repositories, commits, and explicit commit disposition
- - evidence references
- - verification commands and outcomes
- - residual risks
- - whether controller action is required
- - for completed implementation work, exactly one
- `{kind:"acceptance-anchor", anchorId, red, green, ref}` per authored anchor
+ - `outcome` and a non-empty `summary`;
+ - for a product target, `repositoryChanges` containing exactly one
+ `{repositoryId,disposition,commits}` entry matching the
+ assigned repository; for Test, an empty `repositoryChanges` array;
+ - typed `evidenceLocators` entries `{kind,ref,digest}`, reproducible `verification`, and
+ honest `risks`;
+ - for completed non-Test work, exactly one
+ `{kind:"acceptance-anchor",anchorId,evidenceRefs:[{ref,digest}]}` mapping per
+ package anchor, using only declared locator tuples;
- for completed Test work, exactly one
- `{kind:"test-step", planIndex, step, ref}` per approved plan item
+ `{kind:"test-step",planIndex,step,ref}` mapping per approved plan item, in
+ plan order and pointing to one declared locator.
- Complete mapping means only that the target covered the declared anchors or Test
- steps and the result can enter controller review. It does not verify the claims
- and is never automatic acceptance.
+ A same-envelope correction adds the exact `supersedes` result tuple selected by
+ the owner. A first result or new delivery-envelope round must not invent one.
- Do not write real thread ids into tracked documents, prompts, or backfill text.
+ Structural completeness makes a result eligible for controller review. It
+ does not verify claims and is never automatic acceptance. Do not place raw
+ thread handles, private absolute paths, or machine-specific cache paths in the
+ result.