# Task record template

Use one compact Markdown block per task in the project's existing plan or progress document. Omit unused conditional fields. Prefer the project's format; add only missing fields. Do not create a Bearing-owned state file or hidden ledger.

## Current-task hook opt-in

Only after the owner explicitly requests Bearing for this task, record one
`bearing_session` line in the existing visible project plan at the checkout
root (or its existing ancestor plan), alongside that task's block:

```markdown
- bearing_session: {"owner_requested":true,"session_id":"<native session id>","task_id":"<current task id>"}
```

The task must have a nonterminal status. Use the native `session_id`, `sessionId`,
or Cursor `conversation_id`; bind each separately launched session explicitly.
Replace/release the binding when the task changes or completes; never carry an
old request into another task. Installation, role names, profiles, and old plans
or leases do not opt in. Missing, stale, cross-session, or ambiguous bindings
leave ordinary hooks quiet and git-sync inert. This is a field in the existing
project record, not a new file, hidden ledger, daemon, or global switch.
Legacy plans migrate only when the owner requests Bearing for the current task.
Standalone selected/required Test Engineering and explicit `assurance_dispatch`
bindings keep their own capability/authority boundaries and budget enforcement.

## Lifecycle settings

Planning and Design records these plan-level proposals above the task blocks in the
complete five-artifact package. The integrated owner review approves or changes
the lifecycle, profile, role states, reasoning, cadence, and plan together; no
pre-planning profile or route-review gate is allowed.

```markdown
- lifecycle: <direct packet | coordinator wave | orchestrated waves>
- review_cadence: phase
- choice_basis: <proposed recommendation and reason; owner-approved at integrated review>
- profile_snapshot: <named implementation/assurance instances plus the planning_review binding below>
- planning_review:
  - policy_ref: skills/bearing-lite/references/review-policy.md
  - candidate_ref: <shared planning-package reference>
  - candidate_revision: <shared planning-package revision>
  - candidate_digest: <shared planning-package digest>
  - reviewer_slots:
    - slot_id: <abstract unique slot>
      primary_route_ref: <owner-selected profile route reference>
      fallback_route_refs: [<ordered owner-selected route references>]
  - round_number: 1
  - completed_rounds: <0-1>
  - receipts: <one isolated receipt per slot, including the distinct selected_route_ref>
  - aggregated_repairs: <0-1>
  - deterministic_gate: <PASS after repair; otherwise omitted>
```

Cadence values are `slice`, `phase`, or `lifecycle` for each declared phase or
wave. Defaults are `phase` for Test Engineer assurance, `phase` for Reviewer,
and `lifecycle` for Integration Engineer execution. The single independent
review runs on that unit's integrated candidate as soon as its declared cadence
boundary passes deterministic checks, not as task-level tests or author self-checks.
When waves are declared, `phase` cadence resolves to each wave, so wave-end review
needs no separate setting. Never infer it from
`required_assurance` on an individual task. The proposal is visible in
`implementation.json` and the DoD Manifest, then becomes authoritative only
after the integrated owner approval.
`lifecycle` stays a proposal until the mapped implementation graph exists and
the integrated owner review approves it. `profile_snapshot` is authoritative
after that approval. Later
edits to `~/.agents/bearing-lite/profiles.json` have no effect. The `Orchestrator`
row of the snapshot is the observed identity of the session that ran planning
(harness, model, reasoning at that time); it is never a catalog selection and
never a deviation.
Replace it only through an explicit owner-confirmed dated visible amendment.
Record the amendment date beside the replacement values. Dispatch identities
come from this snapshot, not from the current global defaults file.

Every configured planning-review slot uses the same candidate ref, revision,
and digest. Findings stay isolated until one aggregation. Slot exhaustion is
`FAIL_ROUND`; policy violations halt or require an owner amendment. The binding
does not populate `required_assurance` and does not dispatch reviewers.

## Checkout lease (record before any planning write)

The Orchestrator's first write is this visible lease. Inventory nonterminal Lifecycles
first. Do not dispatch or write other planning state until the lease is
`active` for this Lifecycle.

```markdown
- checkout_lease:
  - journey: <Lifecycle id>
  - controller: <Orchestrator>
  - repository: <canonical repository>
  - checkout: <worktree or checkout identity>
  - branch: <branch>
  - candidate_revision: <candidate revision>
  - acquired_at: <acquisition time>
  - generation: <positive integer>
  - state: <active | released>
```

Same checkout plus a live other Lifecycle returns `WAITING_ON` with sanitized
competing Lifecycle and controller identities. Distinct explicitly approved
compatible worktrees may proceed. Resume keeps the same generation and does
not duplicate dispatch. Authorized same-Lifecycle candidate progress whose
parent is the current leased revision refreshes `candidate_revision` on the
same generation. `COMPLETE` or `CANCELLED` releases the lease exactly
once. Stale recovery is explicit, recorded, increments generation, and cannot
steal a live lease. Process discovery cannot replace this durable lease.

## Wave receipt (record at wave start)

Continuations reuse this visible record beside the checkout lease. Validate at
wave start, after detected drift, and before commit — not before every
mutation. Resume from it; do not reread every accepted artifact or redispatch
completed slices.

```markdown
- wave_receipt:
  - wave: <wave id>
  - lease_generation: <generation>
  - branch: <branch>
  - candidate_revision: <revision at last check>
  - authority: <envelope>
  - checked_at: <wave_start | external_change | commit>
```

Stale, forged, or drifted receipts fail closed. Changed HEAD, authority,
generation, route, or writer overlap forces revalidation or a fresh session.

While a review or assurance round is bound to a candidate, write
`.bearing-round.lock` in the checkout (`candidate`, `plan_dir`). Orchestrator
writes under `plan_dir` are deferred until the lock is removed. Independent
roles receive distinct `evidence_dir` values and must not read a sibling
role's directory.

## Always present

```markdown
### task_id: T1
- outcome: <approved user-visible outcome for this task>
- status: PROPOSED
- assigned_role: <role or unassigned>
- depends_on: []
- next_action: <smallest concrete next step>
```

Field rules:

- `task_id` — stable identifier unique within the plan.
- `outcome` — approved intent for this task only. Never a role-return token and never copied into `verdict`.
- `status` — one of `PROPOSED`, `READY`, `WAITING_ON`, `IN_PROGRESS`, `EVIDENCE_READY`, `VALIDATING`, `REVIEWING`, `ACCEPTANCE`, `CORRECTION_REQUIRED`, `OWNER_DECISION_REQUIRED`, `COMPLETE`, `CANCELLED`.
- `assigned_role` — current role contract for the active step, or unassigned while proposing.
- `depends_on` — list of other `task_id` values only, never prose.
- `next_action` — the immediate allowed step.

## Before execution (add when leaving PROPOSED)

```markdown
- scope: <allowed paths, systems, and boundaries>
- authority: <approved envelope; protected actions remain owner-only>
- required_assurance: [Assurance Test Engineer]
```

`required_assurance` lists only roles that must accept the same candidate (for example `Assurance Test Engineer`, and `Reviewer` or `Integration Engineer execution` when their triggers apply).

For requested review, include advance same-session repair authority in the original
packet: exact candidate/session, allocated repair paths and regression tests, one
remaining repair allowance, required deterministic commands and protected-action
holds. Follow `skills/reviewer/references/repair-transition.md`; do not grant new
scope through a receipt. Reviewer starts bug/security OCR and performs complementary
architecture, requirements, implementation/V&V and lint/quality work concurrently,
then validates all findings, freezes one receipt, repairs and verifies in the same
assignment. No parent reproduction/acceptance round-trip is needed. Aggregate any
split review before repair; do not mutate a candidate still under inspection.

The parent declares selected capabilities and frozen enabled/required/mode settings.
For Reviewer coverage assist, the Reviewer resolves backend availability once,
previews the exact candidate and initiates OCR; record the resolved `available`
state before capability execution. Other worker capabilities retain their declared
availability contract. An unselected capability is not activated by discovery;
unavailable required coverage stays a typed gap, never equivalent evidence.

Test Implementer write set is tests and approved fixtures only. Product
write set excludes tests and must not weaken independently authored tests.
Neither self-certifies.

## After candidate work (add when evidence exists)

```markdown
- candidate_ref: <strongest native revision or changed-path reference available>
- changed_paths: <paths changed in this candidate>
- tests: <commands run and observed results>
- findings: <labeled inferences and gaps>
- verdict: <closed role-return token>
- assurance_rounds: <0-1 completed assurance rounds for this declared phase or wave>
```

`verdict` is one of `ACCEPT`, `ACCEPT_WITH_FINDINGS`, `BLOCK`, `CANDIDATE_READY`, `FAIL`, `GAPS`, `NEEDS_MORE_EVIDENCE`, `OWNER_DECISION_REQUIRED`, `PARTIAL`, `PASS`, `READY`, `REPAIR_REQUIRED`, `REROUTED`, `WAITING_ON`. Do not copy task `outcome` into `verdict`.
`candidate_ref` must not claim stronger provenance than the client can prove.
`assurance_rounds` counts this declared phase or wave's single submission to
required assurance against Bearing Lite `max_assurance_rounds`. A repair or
replacement candidate does not reset it; the next distinct declared phase or
wave carries its own budget. The parent
controller writes the count before dispatch: Orchestrator on a direct packet,
Coordinator on a coordinator wave. If the review permits correction, use at
most the one authorized review-directed repair, run deterministic parent-controller
verification (consume applicable repaired-candidate results; no redundant rerun),
and close the gate without another review. A failed repair or
scope change returns `OWNER_DECISION_REQUIRED`.

## Waiting or correcting only

```markdown
- blocker: <WAITING_ON:<task-id> | typed reason | none on success>
- attempts: <observed correction count; no inferred limit>
```

Omit `blocker` and `attempts` when the task is not waiting or correcting. Waiting does not consume correction attempts. Preserve any owner-supplied allowance; no fixed numeric cap is inferred.

`COMPLETE` ends Bearing assurance. An already authorized deployment keeps its
own operational checks and rollback evidence but does not reopen independent
review. Any source or candidate change during deployment is separately scoped.

## Single-writer reminder

Only the parent controller updates this block after rereading it. The parent controller is the Orchestrator on a direct packet and the Coordinator on a coordinator wave. Implementer, Test Engineer, Reviewer, and Integration Engineer execution return compact receipts (`verdict`, `candidate_ref`, `changed_paths`, `tests`, `findings`, `blocker`); the parent controller records transitions. Workers do not edit the plan. Implementer must not self-certify. Orchestrator alone changes cross-wave dependencies or global sequencing. Update `implementation.json` and the DoD Manifest once per wave, plus owner-decision or blocker changes. Direct packets never dispatch Coordinator.