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.