wta-green-impl

# WTA Green-Impl Role The green-impl is the role that writes product code under a sealed task contract. It claims the task, pulls a dedicated worktree, implements the change, runs the local check baseline, and submits the result for blue review. It does not decompose, sign contracts, review, or merge. ## Operating contract This role is *content production* — implementing the sealed task. Claim, pull, edit, run checks, and submit are all mechanism you execute autonomously. There is no judgment to escalate here: you do not review or merge your own work, and you do not decide whether the result is acceptable — `wta submit` enforces the machine floor, and a separate reviewer (a different identity, ideally a different person) renders the verdict. If you are also the reviewer, that verdict is self-attestation and must be labelled as such, never presented as independent review. ## Authority The green-impl may act on: - Claim and pull: `wta take`, `wta pull`. - Edit product source within the worktree. - Run product checks (`cargo fmt -- --check`, `cargo build --locked`, `cargo test --locked`). - Submit: `wta submit`. Plus all read-only commands. ## Stage 1 — Claim ```sh wta take task-NNN ``` The task must be in `ContractsSealed` phase. The claim records the acting fingerprint as the task's owner. Once claimed, no other green-impl can claim the same task. ## Stage 2 — Pull a worktree ```sh wta pull task-NNN ``` WTA creates a local worktree at `.wta/worktrees/<project>/task-NNN/` with three subdirectories: - `product/` — the product source checkout on the task branch `task/task-NNN-<actor>`. This is where edits go. - `contract/` — a local read-only copy of the sealed task contract bundle (intent, task, interface, acceptance) for reference. - `review/` — populated only when pulling as reviewer. Empty for green-impl. The active boundary in the worktree's generated `AGENTS.md` and `CLAUDE.md` reflects role `green-impl`, stage `implement`, task `task-NNN`. Read those files before editing. ## Stage 3 — Implement Edit only files allowed by the task interface's `## Implementation Surface` and `## Allowed Files`. If you find an edit that is needed but lies outside the allowed list, do not silently expand scope; either narrow the change or stop and ask the user (the right answer is usually a follow-up task). Run the local check baseline before submitting: ```sh cargo fmt -- --check cargo build --locked cargo test --locked wta doctor --skip-ssh ``` All four must pass. If a pre-existing `cargo fmt` issue blocks the required check, prefer fixing the formatting via `cargo fmt` and noting the incidental cleanup in the commit message rather than working around it. Commit with the worktree's expected git author identity: ```sh git add <files> git -c user.name="<your-wta-name>" \ -c user.email="<your-wta-name>@wta-dev.invalid" \ commit -m "<task title>" ``` ## Stage 4 — Submit ```sh wta submit task-NNN ``` Submit pushes the task branch to VPS `product.git` and records the delivery commit hash and context fingerprint in artifact.git. The task moves to `Delivered`. After submit, do not amend the committed commit. If you need to fix something post-submit, either accept reviewer judgment or add a follow-up commit on the same branch before the reviewer pulls. Force-pushing a different commit after `wta submit` causes a phase mismatch (the manifest still records the original delivered hash) and is hard to recover cleanly. ## Constraints - Stay inside the active task contract. Do not edit unrelated files, run unrelated commands, or work in another task's worktree. - Do not run `wta sign`, `wta review`, `wta merge`, or any orchestrator-level command. - Do not amend or force-push after `wta submit`. - If `wta agent doctor --task task-NNN` reports stale generated context, run `wta agent render --task task-NNN` before re-running checks. ## Common friction - `wta submit` rejects with "must be Claimed before submit": the task is already at `Delivered` (you submitted before). Move to the review/merge stages, or ask the user how to proceed. - Pre-existing `cargo fmt` failures: apply `cargo fmt` and note the incidental cleanup; better to land a clean check than to pretend the file passed. - Worktree `git status` shows the wrong branch: the wrong task is active; run `wta info` to confirm and `wta pull task-NNN` if needed. ## Read also - [reference.md](reference.md) — worktree layout, commit identity convention, submit semantics, and how to handle pre-existing fmt failures. - [examples/commit-message.md](examples/commit-message.md) — vetted commit message shapes from real dogfood runs.