Update to taskplane

{
  "name": "tp-go",
  "description": "Carry delivery through seven explicitly accepted phases with shared graph, decomposition, dashboard and verified evidence.",
  "included_files": [
    {
      "relative_path": "references/codex-native-dispatch.md",
      "size_in_bytes": 13052
    },
    {
      "relative_path": "references/shared-flow.md",
      "size_in_bytes": 27377
    }
  ],
  "skill_md_contents": "---\nname: tp-go\ndescription: Carry delivery through seven explicitly accepted phases with shared graph, decomposition, dashboard and verified evidence.\n---\n\n# Delivery with explicit approval policy\n\nBefore creating state, apply the [workspace and execution contract](references/shared-flow.md#workspace-and-execution-contract).\nBind Cowork's selected project and validate the user's execution policy before\nactivation or bootstrap writes. A local mount does not establish command or worker\nlocality. Then resolve this installed plugin's runtime and run\n`flow activate --workspace <checkout> --phase tp-go --request-reference <actual-user-request>`.\nInspect `flow report`: reuse the matching active visit or initialize the appropriate\nscoped run before continuing. This requirement includes standalone work and resumed\nstages; loading a skill alone grants no phase approval. See the shared flow for\nbootstrap, native dashboard handoff and legitimate user waits.\n\nRead [the shared flow](references/shared-flow.md) before execution. It owns the\nphase policy, shared artifacts, required evidence and host capability boundary.\nProduct, Design, Plan, Build, Evaluate, Engineering and Retro each require acceptance\nof concrete output before the next phase. Human approval is the default; explicit\nrun-bound authorization may enable policy decisions under the shared flow. The orchestrator\nprepares evidence and advances only after that valid decision; it never self-accepts.\n\nAt each phase use the shared dependency graph, source component decomposition,\ntask DAG and dashboard. Standalone Product, Design and Engineering use the same\ndefaults. Engineering findings can define Product inputs after a human-approved\nroute extension that retains the finding evidence.\n\nDo useful work within the current authorized phase until its output is reviewable.\nBuild follows the accepted Plan's exact paths and prerequisites. Verify affected\nbehavior; repeat checks only after changed inputs, failure or a specific gap.\nEvaluate and Engineering do not silently fix source: propose a scoped repair visit\nfor acceptance. Finish only after every required visit has valid human or authorized policy acceptance.\n\nUse native_workflow inside Codex/Claude: start with an exact scope JSON and the actual\nuser-request reference; submit evidence and record the explicit response using the\nobserved-decision envelope documented in the CLI reference. Every transition still\nrequires a validated checkpoint and the applicable human or policy decision. The local store and provenance are cooperative workflow\ncontrols, not host-authenticated approval or containment. Show workflow availability\nseparately from the four unavailable host protections. An explicitly requested\nprotected_host profile must refuse without its trusted owner; never silently downgrade.\n\nUsage remains advisory. Record meaningful progress and evidence, keep unknown usage\nvisible and use waste advisories to simplify the next deliverable. A telemetry\nfailure does not erase acceptance; missing required phase evidence blocks submission.\nUse [native delegation](references/codex-native-dispatch.md) only when authorized.\n\nKeep event references and observed command handles bound to their conversation,\ncheckpoint and phase revision. Actor labels and hook activity alone never approve.\nKnown live work prevents sealing; a cancellation request is not a completion event.\nIncomplete native process coverage stays unknown in native_workflow and blocks\nprotected_host execution. See [CLI contracts](../../docs/cli-reference.md).\n\nUse `flow policy` only for explicit additional user instructions; preserve their actual\nprovenance, phases, stops and conditions. After each submission, use `flow auto-decide`\nonly when the current policy permits it, then advance. Pause on refusal; never invent\na human response or ask again when a valid explicit policy already authorizes the\ncheckpoint. See the shared flow and CLI reference for the exact envelopes.\n\n## Consume bounded context\n\nAfter activation, start, advancement or resumption, use the installed runtime's\n`flow context --workspace <checkout> --run <run>` and consume the returned\nhandoff with `--consume <handoff-ref-sha256>`. Use `--task <current-task-id>` for\nfocused work. Read every omitted required input using `--read <ref-sha256>`;\nfollow index children and page cursors until all required bodies are returned.\nA fresh consumer receives these bodies, scoped source and relevant findings;\ndo not copy the predecessor conversation or tool history into its instructions.\nNo context operation authorizes dispatch or a phase transition.\n\nFor phase submission, obtain a current whole-phase receipt (without `--task`)\nand include the returned `context_receipt` object in the phase output. Renew it\nafter source, scope, revision or accepted input changes. New bounded/v1 runs\nreject missing, partial, foreign or stale receipts. Legacy runs keep their\noriginal evidence contract. A receipt proves returned data, not model attention.\n\nRoutine command summaries preserve the current gate and reference full details.\nExpand specific references when needed; request `--full` only for a consumer that\nrequires the complete legacy report. Native dashboards retain complete evidence.\nReuse a prior passing check only when its verification record matches current\nsource/dependency, tests, runtime, environment, command and criteria fingerprints.\nRetain failed/unknown results and findings; reuse never transfers approval.\n\n## Scoped native workers\n\nWhen authorized, use the installed native dispatch protocol: root prepares a run-bound\ntask grant, the observed worker claims its identity and consumes its own task context,\nand root verifies the joined result before satisfying dependencies. Fill observed\ncapacity with useful independent work; two is only the minimum live acceptance test.\nWorkers return evidence and cannot operate root phase controls or publish task definitions.\nRequire actual loaded-runtime and native execution evidence for live claims.\n\n\n## Efficient native startup and context\n\nFor every new native task, declare exact `read_inputs` from the run verification\ninputs or accepted Build paths, a concise `purpose`, and `context_budget_bytes`\n(default 128 KiB of unique required bodies). Include source dependencies and tests\nneeded for the conclusion; narrow inputs must not hide a relevant dependency.\nMissing read inputs retain conservative legacy coverage. Inspect preparation's\n`context_preflight` before launch. Declare source/log/test detail artifacts as\n`source`, `raw-log`, `verification` or `supporting`; keep concise requirements and\nreports normative. Use `required_for` when supporting bodies are mandatory.\n\nAlways supply `fork_turns: \"none\"` explicitly. Start the first useful scoped task,\nthen observe its successful claim, complete context and matching automatic pre/post\nhook pair before preparing the rest of the cohort. Scoped preparation enforces\nthis automatically; `readiness_after` can name an additional same-phase startup\nprerequisite. Release remaining ready work together while the first task works.\nDo not use throwaway probes or relaunch unchanged failures. A repeated scoped\nattempt needs `retry_reason` naming the observed defect or changed input.\n\nExecute the exact returned context action. New scoped workers use `--drain`, which\nreturns at most 32 KiB including bodies and receipt. Return every response to the\nconsumer, then follow `next_action` only while `remaining_required` is nonzero.\nTerminal responses have `done: true` and no action. Accumulate all subprocess/tool\nchunks until exit before parsing; never parse a running handle's partial output.\nKeep the combined response budget large enough and use bounded long waits (up to\n60 seconds between user updates), not repeated short model-facing polls.\n\nAfter a narrow repair, repeat affected checks and reviewers only. Unchanged\nscoped results remain fresh within their original binding; across visits use\nindependently fingerprinted check evidence and a fresh scoped delta review.\nNever transfer approval, worker identity or a context receipt to another binding.\nInspect attempt purposes, retry causes and delivered bytes in worker status and\nthe dashboard. Delivered bytes, native tokens and Codex allowance are different\nmeasurements; no allowance saving can be inferred from byte counts alone.\n"
}