project-coordination-setup

name	project-coordination-setup
description	Use when bootstrapping an FB-coordinated project with board, handoff, workstream, and harness routes.

Set up an FB-coordinated project

The bootstrap installs the canonical seven-page FB harness pack and adds or updates a thin managed route in AGENTS.md and .codex/rules.md. Fresh projects receive the pack and routes. On reruns, the bootstrap preserves project-owned text and replaces only a complete block from <!-- fb-harness-route-start --> through <!-- fb-harness-route-end -->; unmatched markers and all text outside that exact boundary remain untouched.

Setup provisions the one six-workstream loop: Product/User (technical slug product), Business, Design, Tech, Discovery, and Bugs. It preserves existing project-owned cards and adds only missing cards. Each relevant workstream runs a mini-loop and records a ready or blocked docs/handoffs/<TASK-ID>.md for the BFM scanner; inactive workstreams need no manufactured work. BFM stops at Ready to ship. Only Push Live authorizes merge or deployment.

The installed start.md defines the single public workstream-first path. After relevant workstreams create ready handoffs, $bfm activates Product reconciliation and execution of approved scope.

• First-project contract and approval boundary
• Board/index/handoff/workstream roles and execution
• Review and verification evidence
• Safety, recovery, sidechat, and escalation policy
• Repository-local session lifecycle and privacy boundary
• Markdown eval lifecycle and Quality Gaps

The installed guardrails.md is also the source for the canonical beginner pause card. Use it for approval waits and genuine stops.

After setup, each matching workstream owns its investigation and ready handoff. Product owns reconciliation and sequencing only after $bfm; source-changing execution starts through that approved BFM boundary.

The installed harness retains private agent routing and keeps package mirrors generated from canonical root files. Do not add a second board/index/session record for Quick BFM; its single Quick Record and local Efficiency Receipt are the durable boundary.

The harness distinguishes focused checks, immediate safety gates, and release checkpoints. A full validator needs an explicit Product-owned release-checkpoint request; a Markdown handoff artifact or review transfer alone is not one. Its generated Quick Records state whether review is required: documentation and coordination use zero reviewers after focused checks pass, runtime and test use exactly one, and records without the field retain the legacy one-reviewer rule. Projects may configure hooks.focusedTest and a timeouts.focusedTestMinutes value of at most 10 in .fb-lane.json; otherwise runtime Quick work uses bounded npm test. The 5- or 15-minute target applies to one execution slice, not the complete outcome. During $bfm, split predictable work up front into the smallest useful dependency graph. Full BFM may coordinate many slices for hours and use parallel agents or subagents for independent, non-overlapping locks. Keep dependent, shared-file, sensitive, and unresolved-decision work sequential; verify each slice narrowly and reserve broad validation for the release checkpoint.