skills/nacl-tl/resources/workflows/nacl-tl-full/SKILL.md

---
name: nacl-tl-full
description: |
  Coordinate NaCl TL full lifecycle execution from graph-backed waves and tasks
  through development, review, verification, and final reporting with explicit
  Codex contracts. Use when running the full graph-aware TL workflow or
  compatibility with `/nacl-tl-full`.
---

# NaCl TL Full For Codex

## Packaged Gateway Binding

Read [`the packaged gateway binding`](../../references/workflow-gateway-contract.md)
and use only its `tl-task` sequence. Allocate or claim a `Task`, retain and
heartbeat its lease/fence, mutate with revision CAS and
`APPROVE_TL_WRITE`, read back, then release or explicitly hand off. Never
advance `done` or `verified-pending` without parseable evidence in that same
mutation.

Read `../nacl-tl-core/SKILL.md` and `../nacl-tl-core/references/tl-codex-contract.md` before executing this workflow.

Coordinate graph-aware TL execution without assuming a separate isolated runner.
TL artifacts and reports remain English.

Read `../references/orchestration-model.md`,
`../references/migration-rules.md`, `../references/verification-vocabulary.md`,
`../nacl-core/SKILL.md`, and `../nacl-tl-conductor/SKILL.md` before executing
this skill.

## Goal Compatibility

This skill can be a target behind `nacl-goal` only through the `wave:<N>`
alias. Load the internal workflow `../nacl-goal/SKILL.md` and
`../references/goal-codex-contract.md`.

Codex itself must not claim that Anthropic `/goal` ran unless the runtime
exposes it and evidence exists. Load
[`the packaged wave proof method`](../../nacl-goal/checks/wave.sh) as an internal
reference; do not expose it as a project-cwd shell command. GOAL_PROOF is
transcript evidence for the evaluator, not a replacement for local
verification. Use the closed Codex status vocabulary when the wrapper cannot
run.

## Contract

Inputs consumed:

- graph-backed `Wave` and `Task` records when graph access is available;
- `.tl/master-plan.md`, `.tl/status.json`, and `.tl/tasks/` when file access is
  available;
- project configuration for graph, task, build, test, or external workflow
  settings when file access is available;
- downstream implementation, review, synchronization, QA, documentation, and
  stub reports using the closed verification vocabulary.

Outputs produced:

- execution plan with selected wave or task scope;
- per-task and per-phase status table using only the closed verification
  vocabulary;
- graph and `.tl/status.json` update plan, or confirmed updates when tooling and
  permissions are available;
- final lifecycle report with evidence and unresolved problems.

Downstream consumers:

- human user;
- TL conductor workflow;
- delivery or release workflow;
- project status and diagnostics workflows.

## Orchestration Rules

- Use the shared Codex orchestration procedure from
  `../references/orchestration-model.md`.
- Each phase handoff must state inputs consumed, expected output artifact or
  graph change, allowed verification status, downstream consumer, and handling
  for `VERIFIED`, `FAILED`, `PARTIALLY_VERIFIED`, `BLOCKED`, `NOT_RUN`, and
  `UNVERIFIED`.
- Use supported tools, direct local execution, or supported delegation only when
  available in the current Codex environment.
- Collect, parse, and inspect every downstream result before changing phase
  state or advancing to the next step.
- When writing a terminal `Task.status` to the graph, also write
  `Task.verification_evidence` per `../references/verification-evidence.md`.
  Compose evidence from the downstream report's regression-test path
  (`test-GREEN:<path>`), or use `test-UNVERIFIED` per the taxonomy. A `no-test`
  override requires the separate exact mutate input
  `evidence_confirmation: CONFIRM_NO_TEST_EVIDENCE`; absent or wrong
  confirmation is `BLOCKED` before graph access. A terminal `done` write
  without parseable evidence is a writer contract violation; report
  `Status: BLOCKED` rather than write empty.
- A review or verification phase cannot be marked `VERIFIED` unless its check
  actually ran and the result was inspected.
- Ask for explicit user confirmation before graph writes, file writes,
  destructive actions, delivery actions, or the first execution phase.
- If the user approved an autonomous run, continue within the confirmed scope,
  but still stop for missing tools, unsafe actions, or scope changes.

## Parameters

Supported compatibility phrases:

- `/nacl-tl-full`
- `/nacl-tl-full --wave N`
- `/nacl-tl-full --task UC###`
- `/nacl-tl-full --feature FR-NNN`
- `/nacl-tl-full --yes`

Removed in W9-ci-clean-checkout:

- The SKIP-PLAN full-lifecycle flag formerly accepted by this skill
  — Phase 0 already auto-detects an already-populated graph
  (Task/Wave nodes present) and skips the planning subagent launch
  in that case. The flag was redundant; its only remaining use was
  bypassing planning when the graph WAS empty, which is precisely
  the case planning exists to handle. There is no inline override
  that resurrects the flag.

Removed in W3-blocking-qa:

- The bulk-QA-skip flag formerly accepted by this skill — QA bypass
  at the full-lifecycle layer is no longer an operator flag. For
  stage-level skips of `LIVE_PROVIDER_SMOKE` / `PROD_GOLDEN_PATH`
  only, invoke `/nacl-tl-qa UC### --skip-e2e` directly. If a
  mandatory stage ends up `NOT_RUN`, aggregate is forced to
  `UNVERIFIED` and a W4 signed exception is required to advance.
  Bulk-bypass needs route through W4 emergency mode.

Treat parameters as scope and gate preferences. They do not imply that any
specific delegation mechanism exists.

## Workflow

### Phase 0: Initialization

Check graph connectivity and graph schema availability when graph tools exist.
Probe for `Task` and `Wave` records. If graph access is unavailable, report
`BLOCKED` unless the user explicitly changes scope to a non-graph workflow.

Check `.tl/` planning files when file access exists. If planning is missing,
run or invoke the planning procedure only when the current environment
supports it and the user confirms. If planning is already populated (Task and
Wave records present in the graph), skip the planning procedure silently —
the previous SKIP-PLAN flag was removed in W9-ci-clean-checkout because
graph-state detection makes it unnecessary.

Stop and present the detected plan, selected scope, not-run phases, and required
confirmation unless `--yes` was explicitly provided.

### Phase 1: Wave 0 Technical Tasks

For each technical task in scope, coordinate development and review.

Contract:

- Inputs: task graph record, task file when available, dependencies, and current
  status.
- Expected output: implementation report, review report, graph update request,
  and status-file update request.
- Downstream consumer: later waves and final report.
- Verification: inspect implementation and review reports before advancing.

If required implementation or review procedures are unavailable, report
`BLOCKED`. If a procedure runs but evidence cannot be checked, report
`UNVERIFIED`.

### Phase 2: Use Case Waves

Process waves in graph order unless the user selected a single wave, task, or
feature scope. Respect graph dependencies before starting a use case.

Each use case lifecycle has these steps:

1. Backend development.
2. Backend review.
3. Frontend development.
4. Frontend review.
5. Backend-frontend synchronization.
6. Stub scan.
7. QA (the `nacl-tl-qa` skill applies its six-stage decomposition and aggregate rule; the bulk-QA-skip flag was removed at this layer in W3).
8. Documentation.

Contract for each step:

- Inputs: task file, current graph phase state, previous step result, and needed
  project files.
- Expected output: step report, evidence, and proposed task phase transition.
- Downstream consumer: next lifecycle step and final report.
- Verification: parse the downstream report and map it to the closed vocabulary
  before advancing.

Do not skip review, synchronization, stub scan, or documentation. If QA is
not executed by confirmed parameter, report that step as `NOT_RUN` and make the use
case aggregate `UNVERIFIED` unless later evidence verifies it.

### Phase 3: State Updates

Graph is the primary state when graph tooling is available. `.tl/status.json` is
secondary compatibility state when file access and write permission exist.

Before writing either store, present the intended transition and ask for
confirmation unless the user already confirmed autonomous writes for the current
scope.

If graph write cannot be completed, do not advance the phase. Report `BLOCKED` with the task,
phase, and reason. If graph and file state diverge, report `UNVERIFIED` until
diagnostics reconcile the state.

**Remote mode (multi-user shared graph):** the above is local mode (`config.yaml` `graph.mode`
absent or `local`). When `graph.mode: remote`, the graph is the SOLE source of truth and
`.tl/status.json` is a best-effort per-clone cache: a successful graph write advances the phase;
resume reads the graph only (no stale-cache fallback — HALT if the graph is unreachable). Before
working a task, call `project MCP derive worker identity operation`, then
`project MCP claim resource operation` for the exact `Task` with a stable idempotency key,
bounded TTL, and `APPROVE_TL_WRITE`. Retain the returned fence, heartbeat long
work with `project MCP heartbeat resource operation`, mutate only with that fence and
revision CAS, and finish with `project MCP release resource operation` or an explicitly
confirmed `project MCP handoff resource operation`. Stamp returned identity provenance on
phase writes. Load
[`the packaged remote coordination reference`](../../nacl-tl-core/references/remote-mode-coordination.md);
never shell to a package path or infer one from the project cwd.

### Phase 4: Final Validation

Before final reporting, verify every scoped task reached a terminal outcome in
the closed vocabulary. Query graph state when possible and inspect `.tl/` state
when available.

Run final stub or QA checks only when tools are available and scope permits. If
some checks cannot run, use `PARTIALLY_VERIFIED`, `NOT_RUN`, `BLOCKED`, or
`UNVERIFIED` as appropriate.

### Phase 5: Final Report

Return:

```text
Item | Phase | Status | Reason | Evidence
```

Include not-run checks, blocked tools, unsatisfied phases, unchecked downstream
outputs, graph-write results, file-write results, and recommended next
confirmed action.

## Status Mapping

Use only these verification statuses:

- `VERIFIED`
- `FAILED`
- `PARTIALLY_VERIFIED`
- `BLOCKED`
- `NOT_RUN`
- `UNVERIFIED`

When a downstream report uses other wording, map it to the closed vocabulary and
include the original wording only as evidence if needed. Do not create a new
top-level status.

## Resumption

When existing graph or `.tl/` state indicates incomplete progress:

- identify the first incomplete phase for each scoped task;
- verify dependencies before continuing;
- present the resume point to the user;
- ask for confirmation unless `--yes` was explicitly provided;
- continue from the confirmed phase only after previous phase evidence has been
  inspected.

If the resume point cannot be established, report `UNVERIFIED` and request
diagnostics or user direction.

## Capabilities

### May Do

- Coordinate graph-aware TL execution across waves, tasks, and lifecycle steps.
- Read project configuration, graph state, `.tl/` files, and reports when
  available.
- Use supported development, review, verification, and documentation procedures.
- Propose or perform confirmed graph and file state updates when tools and
  permissions are available.
- Inspect downstream outputs before advancing state.

### Must Not Do

- Assume isolated delegation exists.
- Select or constrain the runtime.
- Modify source root skill folders.
- Mark a phase `VERIFIED` without executed and inspected evidence.
- Write graph state, edit files, run destructive actions, or deliver changes
  without the required confirmation.
- Use statuses outside the closed verification vocabulary.

### Conditional Tools And Actions

- Graph reads and writes require available graph tooling and confirmed scope.
- File reads and writes require workspace access; writes require confirmation.
- Tests, builds, QA, and external workflow updates require configured tools.
- Git, delivery, release, and destructive actions require explicit user
  confirmation.
- Delegation is conditional on Codex-supported mechanisms available in the
  current environment.

### Blocked Or Unverified Reporting

- Use `BLOCKED` when required inputs, tools, permissions, infrastructure, or
  confirmation are unavailable.
- Use `NOT_RUN` when a phase is intentionally not executed.
- Use `PARTIALLY_VERIFIED` when only some required checks ran.
- Use `UNVERIFIED` when downstream output, graph state, or file state cannot be
  checked.
- Use `FAILED` with a reason when a phase violates its contract or new breakage
  is detected.

## Source Comparison

- Source Claude skill path: `../../nacl-tl-full/SKILL.md`

### Preserved Methodology

- Graph-backed waves and tasks as primary execution scope.
- Full TL lifecycle across development, review, sync, stubs, QA, docs, and final
  reporting.
- Resume from graph or `.tl/` state.
- State consistency between graph and local TL status files.

### Removed Claude Mechanics

- Runtime routing fields in frontmatter.
- Assumed isolated wave and phase execution.
- Source-specific execution commands for unsupported delegation.
- Status labels outside the closed verification vocabulary.

### Codex Replacement Behavior

- Coordinate lifecycle steps through explicit contracts and inspected outputs.
- Treat graph, file, test, external workflow, and delegation actions as
  conditional.
- Preserve start, write, delivery, and scope-change confirmation gates.
- Report blocked, incomplete, not-run, unsatisfied, or unchecked outcomes with the
  closed vocabulary.