Executing

If preflight readiness is missing, stale, or blocked (check .pulse/tooling-status.json), stop and invoke pulse:using-pulse before continuing.

pulse:executing supports two modes:

• worker mode under pulse:swarming
• standalone single-worker mode when preflight recommends degraded execution

In both modes, the live bead graph is the source of truth for what to do next.

Loop Overview

Initialize → Get Bead → Reserve Files → Implement → Verify → Close & Report
     ↑                                                               |
     └─────────────── Context OK? Loop ─────────────────────────────┘
                       Context >65%? → Handoff → Stop

Step 1: Initialize

Determine mode from invocation plus .pulse/tooling-status.json:

• if invoked by pulse:swarming, run in worker mode
• if recommended_mode=single-worker, run in standalone mode

1a. Restore Worker Bootstrap Context (worker mode only)

Swarming gives you runtime-native startup context. Capture and keep these fields together for the rest of the run:

• runtime_identity
• coordinator_identity
• adapter_name
• epic_id
• feature_name
• optional startup_hint

Treat startup_hint as a hint, not a silent permanent assignment. Re-check the live graph before you claim work.

Do not invent extra registration, inbox, or topic mechanics if the active runtime does not use them.

1b. Read Project Context (in this order)

1. AGENTS.md — project operating manual (mandatory; skip nothing)
2. If present, run node .pulse/scripts/pulse_status.mjs --json — quick onboarding/state/handoff/reservation scout
3. .pulse/state.json — machine-readable routing snapshot
4. .pulse/STATE.md — current project focus, decisions, active blockers
5. history/<feature>/CONTEXT.md — locked decisions that MUST be honored

If any of these files does not exist, note the absence and proceed — do not fabricate content.

If the bead references learning_refs, read those specific learning files. Do not load all learnings by default.

1c. Report [ONLINE] Before Claiming Work (worker mode only)

Before you select a bead, you must report in on the active coordination surface. Startup is not complete until you:

1. read AGENTS.md
2. load pulse:executing
3. post [ONLINE] including:
   • runtime_identity
   • AGENTS.md: read
   • pulse:executing: loading
   • Next step: bv --robot-priority

Do not call bv --robot-priority before this sequence is complete.

Runtime mapping:

• Claude Code -> send the startup acknowledgment to the coordinator with SendMessage
• Codex -> reply on the parent coordination thread
• otherwise -> use the active coordination surface defined by the runtime adapter

1d. Check for Handoff

Use owner-scoped handoffs:

• worker mode -> .pulse/handoffs/worker-<runtime_identity>.json
• standalone mode -> .pulse/handoffs/single-worker.json

If a handoff exists and was written by a prior instance of you (same worker identity):

1. Read it — restore active bead, progress markers, open questions
2. Resume from where it stopped; skip re-reading already-read files
3. Archive or mark the handoff consumed and update the manifest

A worker must not consume another worker's handoff directly.

1e. Exceptional path: coordinator-reassigned orphaned worker handoff

Normal path stays same-runtime-identity resume.

Only the coordinator may reassign an orphaned worker handoff when the original runtime identity is unavailable.

Before you resume from a reassigned handoff, require coordinator confirmation that all are true:

• prior worker inactivity was confirmed
• file reservations for the prior owner were checked and are safe for transfer
• same-branch commit queue state was checked and is safe for transfer

For reassignment, the coordinator must update .pulse/handoffs/manifest.json and the owner handoff file before any worker resumes, recording:

• previous owner
• new owner
• reason
• coordinator approval

If those updates are missing, do not resume from the handoff.

Step 2: Get the Next Bead

In worker mode, every loop starts with coordination visibility, not blind bead selection.

Check the active coordination surface for:

• new coordinator instructions
• unresolved blocker replies
• conflict decisions
• handoff or recovery instructions that affect your next move

Then follow the normal path from the live graph:

bv --robot-priority

Select the top-ranked bead that:

• has no open dependencies
• is not reserved by another worker
• is compatible with the current mode

Exceptional path: direct orchestrator hint

If swarming suggests a bead via the active coordination surface, treat it as a startup hint or rescue instruction, not as a permanent assignment. Re-check the live graph before claiming the work.

Read the bead fully

br show <bead-id>

Minimum fields to confirm:

If any required field is missing, stop and bounce the bead back to validating or planning. Do not guess from free-form prose.

If testing_mode is tdd-required, confirm tdd_steps is present before implementation starts.

Current-work artifact read rule for non-trivial beads

Do not rely on the bead alone when the work is architecturally or operationally sensitive.

Before reserving files or writing code, read the active-shape current-work artifacts whenever any condition below is true.

Shape artifact requirements:

• work-shape path: read history/<feature>/work-shape.md (current work is defined directly there)
• epic-map path: read history/<feature>/epic-map.md and history/<feature>/current-story-pack.md
• phase-plan path: read history/<feature>/phase-plan.md, history/<feature>/phase-<n>-contract.md, and history/<feature>/phase-<n>-story-map.md

Trigger conditions:

• testing_mode is tdd-required
• the bead touches multiple files across different modules or ownership boundaries
• the bead has multiple upstream dependencies or explicitly references story coordination, parallelism, shared file/context risk, or boundary preservation
• the verify path is multi-step, integration-heavy, or hard to explain in one line from the bead alone
• after reading the bead, more than one plausible implementation path still seems possible

Use the active-shape artifact set as the canonical current-work contract for this bead.

For beads that touch module interfaces, ownership boundaries, or HIGH-risk constraints, also read the relevant parts of history/<feature>/approach.md.

If the bead is a small single-path change with tight file scope, unambiguous verification, and no boundary sensitivity, the bead plus CONTEXT.md is usually sufficient.

Step 3: Reserve Files

In worker mode, reserve all listed files before editing with the shared repo-local helper.

Repeat --path for every declared file or glob you need to claim:

node .pulse/scripts/pulse_reservations.mjs reserve --agent <runtime_identity> --bead <bead-id> --path "src/foo.ts" --path "src/bar.ts" --json

In standalone mode, there is no cross-worker race, but still treat the bead's files list as a hard scope boundary. Do not blend multiple beads into one ad hoc change, and do not sneak in temporary cross-module structure that was not planned.

If reservation fails in worker mode

1. Post [FILE CONFLICT] immediately on the active coordination surface
2. Include:
   • bead ID
   • requested