feat(runtime): add durable expert-team collaboration

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.

[Nyvo-io]

Summary

This adds the first backend-only collaboration slice for Maka expert teams, building on the existing expert fan-out/fan-in runtime and Task Ledger ownership model.

• add a durable, append-only mailbox scoped by session, team, and parent lead AgentRun
• support bounded role-addressed direct messages and broadcasts with trusted sender AgentRun/Turn attribution
• expose trusted-context team_message / team_inbox tools to leads and members
• let child agents discover tasks owned by the current lead run and atomically claim one available Task Ledger item
• settle claimed task evidence across success, failure, cancellation, waiting-permission, timeout, and startup-error paths without auto-completing successful work
• document replay/restart boundaries and wire one shared mailbox/task ledger through the desktop runtime

Safety and ownership semantics

• The parent/lead remains the final adjudicator; child messages and successful results are evidence, not completion authority.
• A child cannot steal an in-progress task, claim work from another lead run, or claim more than one task per child turn.
• Agent/team/run identity comes from trusted runtime context rather than model-controlled arguments.
• Direct recipients are stable role addresses within one parent lead run. Repeated or concurrent invocations of the same member share that role mailbox, while each caller owns its after_seq cursor.
• Mailbox histories fail closed on corruption, non-monotonic cursors, duplicate message IDs, invalid identities, or lead attribution outside the parent run.
• This PR does not add invocation-private inboxes, renderer UI, automatic message wakeups, remote/cross-machine workers, marketplace behavior, or worktree writes.

Verification

• npm run build:test
• npm run lint
• npm run typecheck
• npm run test:dist — all workspace tests passed
• focused core/runtime/storage mailbox and team-tool tests — 16 passed

Related to #544.

Builds on the expert dispatch work in #971 and Task Ledger child ownership/review semantics in #956; it does not duplicate those slices.

[Astro-Han]

Approved.

Non-blocking P2 follow-up: direct-message recipients are keyed only by the stable agent ID, so repeated or concurrent dispatches of the same member within one lead run share a role inbox. A fresh child invocation can therefore read direct messages intended for an earlier invocation. Please either scope recipient identity/cursors to the child run/turn, or explicitly document and test role-mailbox semantics.

[Nyvo-io]

@Astro-Han Addressed the non-blocking P2 in d4fdbd0 by making the existing role-mailbox semantics explicit and tested.

• Direct recipients are now documented in the core contract, tool descriptions, and runtime docs as stable role addresses within one parent lead run, not invocation-private addresses.
• Repeated and concurrent dispatches of the same member are covered at the runtime and storage boundaries; the tests lock shared history plus caller-owned after_seq cursors, including fresh-invocation replay.
• The follow-up review also found that persisted replay did not enforce the live-send invariant for lead attribution. isAgentMailboxMessage now rejects a lead whose runId differs from parentRunId, with a RED-to-GREEN regression test.
• The branch was rebased and the prior conflict is resolved.

The current typecheck, test, and e2e checks all pass, and the PR is mergeable/clean.

[Astro-Han]

LGTM! Merging.