# Shared References > Shared Hard Invariants referenced by team coordination skills. Do not install directly; load as a cross-reference from collaborate-as-agent-team-member. - Skill: `cyl19970726/shared-references` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add cyl19970726/shared-references` - Raw SKILL.md: https://api.skillmd.com/api/skills/cyl19970726/shared-references/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: cyl19970726 (https://skillmd.com/u/cyl19970726) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/cyl19970726/shared-references --- # Shared Hard Invariants ## Local product responsibility views When the local AgentFirm Dashboard is available, read responsibility state from the five `agentfirm.role_views.v1` endpoints documented in `docs/agentfirm-role-views.md`. Treat SSE only as an invalidation signal and refetch the view. Never rebuild Global-Work/Team/Host/Member/Operator state by joining raw ledgers, and never treat an `AllowedAction` as authority when it has a `disabled_reason`. These rules bind the Host Lead and every Agent Team Member. The Member-facing skill (`collaborate-as-agent-team-member`) references this file; the Host-facing `orchestrate-mission-waves` skill was archived by DOC-108. Where this file and a canonical doc (ADR, schema, product doc) conflict, the canonical doc wins. ## 1. No Assignment Message Compatibility Path Agent Team responsibility is only through the shared Works board. There is no Assignment Message compatibility path and no Harness Goal, Plan Gate, retired Task Graph, or second task ledger. Current peer Works may form one hard dependency DAG; only a versioned Work operation changes its edges and only the kernel derives readiness. A Message is conversation only; never treat one as responsibility, ownership, status, or a dependency mutation. ## 2. One Execution Driver Per MemberRun Each active MemberRun/native session has exactly one top-level execution driver: - `host_driven`: Harness starts the next eligible Provider cycle. Every managed runtime. - `user_driven`: only for declared `external_interactive` members; a human drives their own session. There is no third driver: ADR 0067 retired `provider_driven`. A provider-native goal is a member-internal execution aid, never a second scheduler. Explicitly separate Sessions may share a cwd. Coordinate concurrent writes through separate worktrees or an explicit integration boundary; a shared cwd does not combine their execution drivers. Never activate a native Goal and also start ordinary Harness cycles for the same Work. Provider Goal satisfaction, Provider turn completion, transport receipt, Work submission, and Work acceptance are different facts. ## 3. Provider-Native Session Is Sole Execution Truth The provider's native session store is the sole execution truth for a member's transcript, tool calls, commands, file events, and provider turn lifecycle. Never reconstruct a session from Harness messages. ## 4. Messages Never Change Work State Message is authored conversation only. A message may explain scope, a blocker, a result, or a review decision, but it never changes Work owner or status. If conversation creates durable follow-up, create eligible unassigned Work explicitly, then use canonical membership assignment or claim. ## 5. Independent Acceptance Separates Submission From Done Submission moves Work to `review`; it does not imply acceptance. Ordinary Member-owned Work requires explicit acceptance by the exact Team Host. A Host cannot accept its own Work; one exact active non-owner Team peer in the same TeamRun may accept Host-owned Work. That peer cannot accept another Member's Work and is not a second durable Reviewer role. Treat `review` as non-terminal: submission without the authorized explicit acceptance blocks TeamRun completion. ## 6. Provider-Native Subagents Are Internal Only A Member may use Provider-native subagents for authorized bounded internal lanes. They operate within the parent's workspace arrangements and permission ceiling and return evidence to the parent. Invoking a subagent does not create Harness membership, assign Work ownership, or grant Work acceptance authority. An explicitly authorized subagent may independently review a repository Development Task when its applicable review procedure permits that reviewer. Bind the review to the exact submitted revision and keep implementer and reviewer separate. This does not waive required reviewer qualifications or substitute for an independent AgentMember when the Task requires live Agent Team evidence. Work acceptance still follows ยง5; a subagent's review alone never accepts Work. ## 7. Dependencies And Delegation Never Auto-Complete Responsibility Works are flat peer nodes, never containment nodes. A Work may have many hard prerequisites and many derived successors. Claim or start only when the server says every prerequisite is accepted. A failed or cancelled prerequisite requires Host replan; do not infer downstream failure, cancellation, rewiring, or acceptance. A Team's Work is accountable to that Team and the Work model carries no cross-Team edge; cross-machine collaboration is the separate Remote Fabric surface. An accepted prerequisite never auto-submits or auto-accepts another Work; its owner remains accountable for integration and submission. ## 8. No Plan Mode / No Plan Gate Harness has no Plan Mode or Plan Gate. When the Host wants a plan first, it asks through an ordinary correlated Markdown message; the Member replies, and the Host argues or approves in the same chain. Provider-native plan/goal features are optional internal aids; they are not Harness state or Host acceptance. ## 9. Work Ownership Survives Work identity and stable AgentMember/TeamMembership responsibility persist across WorkEvent history, re-plans, crashes, and runtime restarts. MemberRun and AgentSession generations are exact execution authority, not Work ownership. Never clear responsibility, duplicate side effects, or reconstruct a session from Harness messages after a crash. Each execution attempt requires its own monotonic WorkExecutionBinding and WorkDelivery. A request-changes review โ€” by the Host, or by the exact peer of Host-owned Work โ€” returns Review โ†’ Open; the scheduler then admits the next exact binding/delivery generation. A compatible Workspace and provider-native session may continue, but continuity never substitutes for exact runtime admission. ## 10. Cross-Node Routing Has One Truth `CompanyNode.id` is the existing `ExecutionNode.id`. A NodeGateway is a child of the exact current NodeDaemonLease generation, not a second Node authority. For cross-Node operations, FabricStore `RoutedOperation`, `RouteAttempt`, and `RouteReceipt` are the sole route truth; there is no second route record to dual-write or replay from. A routed Message must carry the canonical immutable Message envelope or an authenticated content-addressed reference; the target persists and verifies it before creating MessageDelivery. RouteAttempt proves transport only; only a generation-fenced target result proves application effect. Unknown effect requires reconciliation and never permits blind replay.