beo-onboard

Purpose

Verify and repair managed beo startup surfaces.

Primary owned decision

Determine whether managed startup is current and repair only the managed onboarding surfaces.

Ownership predicate

• Managed startup freshness is false, missing, or stale.
• AGENTS.md, .beads/onboarding.json, or .beads/beo_status.mjs needs managed repair.
• The user explicitly requests onboarding check or repair.
• The request is not doctrine editing or runtime readiness authorization.

Dependencies

Machine-readable dependency posture lives in frontmatter. Missing br or bv degrades live inspection only; onboarding does not authorize runtime readiness.

Writable surfaces

• Root AGENTS.md managed block.
• .beads/onboarding.json and .beads/beo_status.mjs generated by the onboarding script.
• Narrow exception: may write only STATE.json.status to the value needs_onboarding, and only when managed startup freshness is false, missing, or stale. No other STATE.json fields are writable by this skill.
• No runtime artifacts except startup-orientation metadata.

Canonical: beo-reference → pipeline.md Locally enforced as:

• Onboarding never authorizes PASS_EXECUTE.
• Runtime readiness remains owned by beo-validate.
• Execution-set mutation remains owned by beo-execute.

Hard stops

• Do not edit doctrine as onboarding repair.
• Do not create approvals, route decisions, or execution readiness.
• Do not add runtime execution-set classification to onboarding.
• Flag when .beads/STATE.json shows multiple feature candidates — one active feature per worktree is a system invariant; report the collision and route to user.
• Do not write STATE.json.status=needs_onboarding when STATE.json.current_owner is a live runtime owner (beo-execute, beo-review, beo-validate, beo-plan, beo-explore, beo-debug, beo-compound, beo-dream). In this case, report onboarding staleness as a warning in output only and route to user to resolve the conflict between live execution state and onboarding freshness. The operator must decide whether to pause the active workflow before onboarding repair proceeds.

Allowed next owners

• beo-route — only for exceptional owner-state resolution under canonical route doctrine.
• user

References

• beo-reference → operator-card.md — read when reporting onboarding status.
• beo-reference → state.md — read when describing startup state and handoff freshness.
• beo-reference → artifacts.md — read when listing conditional artifact reads.
• beo-reference → pipeline.md — read when explaining startup orientation versus routing authority.
• references/onboarding-flow.md — read when checking or applying managed onboarding surfaces.