macp-sdk-typescript 0.9.0 → 0.11.0

package/dist/projections/task.d.ts

@@ -1,4 +1,4 @@
-import type { ProjectionAnomaly } from './base';
+import { BaseProjection } from './base';
 import type { Envelope } from '../types';
 import type { ProtoRegistry } from '../proto-registry';
 export interface TaskRecord {
@@ -33,58 +33,35 @@ export interface TaskFailureRecord {
     retryable: boolean;
     sender: string;
 }
-export declare class TaskProjection {
+export declare class TaskProjection extends BaseProjection {
+    protected readonly mode = "macp.mode.task.v1";
     readonly tasks: Map<string, TaskRecord>;
     readonly updates: TaskUpdateRecord[];
     readonly completions: TaskCompletionRecord[];
     readonly failures: TaskFailureRecord[];
-    /**
-     * The session's accepted history, one envelope per unique `message_id`. See
-     * `BaseProjection.transcript` (`src/projections/base.ts`) for the full
-     * redelivery-idempotence contract (RFC-MACP-0006 §3.2); duplicated here
-     * only as a one-line pointer.
-     */
-    readonly transcript: Envelope[];
-    /**
-     * Cardinality anomalies recorded while replaying this projection's accepted
-     * transcript. See `BaseProjection.anomalies` (`src/projections/base.ts`)
-     * for the canonical description; duplicated here only as a one-line
-     * pointer. No built-in detection populates this for Task mode.
-     */
-    readonly anomalies: ProjectionAnomaly[];
     phase: 'Pending' | 'Requested' | 'InProgress' | 'Completed' | 'Failed' | 'Committed';
-    commitment?: Record<string, unknown>;
     /**
-     * `message_id`s already applied to this projection. See
-     * `BaseProjection.seenMessageIds` (`src/projections/base.ts`) for the full
-     * redelivery-idempotence rationale (RFC-MACP-0006 §3.2); duplicated here
-     * only as a one-line pointer.
-     */
-    private readonly seenMessageIds;
-    /**
-     * Apply one envelope to this projection's in-process state.
+     * The **session-level** active assignment: who currently holds the session's
+     * single assignee slot, and which `task_id` they took it on.
      *
-     * Input contract: **accepted-only**, caller-maintained (`Envelope` carries
-     * no acceptance marker). Canonical source: `schemas/conformance/README.md`
-     * "Notes:", RFC-MACP-0007 §5.3, RFC-MACP-0011 §5. Full rationale and failure
-     * mode are documented once, on `BaseProjection.applyEnvelope`
-     * (`src/projections/base.ts`), and duplicated here only as a one-line
-     * pointer so six independent copies of the same prose cannot drift.
+     * RFC-MACP-0009 §5 rule 3 (`:69`): "Only one assignee may become active for
+     * the Session in base v1." The constraint is scoped to the *Session*, not to
+     * a `task_id` — rule 1 (`:67`) separately caps a v1 session at one
+     * `TaskRequest`, so in a conforming transcript the two scopes coincide, but
+     * an unfiltered transcript carrying two `TaskRequest`s must not be able to
+     * hand out two active assignees. That is why this is one field on the
+     * projection rather than a per-`TaskRecord` flag (issue #71).
      *
-     * Redelivery idempotence: a redelivered envelope (same `message_id`) is a
-     * non-event — not appended to `transcript`, not passed to the `switch`.
-     * See `BaseProjection.applyEnvelope` for the full RFC-MACP-0006 §3.2
-     * citation; duplicated here only as a one-line pointer.
-     */
-    applyEnvelope(envelope: Envelope, protoRegistry: ProtoRegistry): void;
-    /**
-     * True once at least one `ProjectionAnomaly` has been recorded. See
-     * `BaseProjection.hasAnomalies` (`src/projections/base.ts`) for the
-     * canonical description; duplicated here only as a one-line pointer.
+     * `sender` is the envelope sender, not `TaskAcceptPayload.assignee`, to
+     * mirror the reference runtime: `macp-runtime`
+     * `crates/macp-modes/src/mode/task.rs:211` sets `state.active_assignee =
+     * Some(env.sender)` after rejecting any payload whose `assignee` disagrees
+     * with the sender (`:205-207`). `taskId` is retained so a reject can clear
+     * the right `TaskRecord.assignee` even on a multi-task transcript.
      */
-    get hasAnomalies(): boolean;
-    get isCommitted(): boolean;
-    get isPositiveOutcome(): boolean | undefined;
+    private activeAssignment?;
+    /** Handle a Task-mode envelope. See `BaseProjection.applyEnvelope` for the accepted-only input contract and redelivery/rollback semantics shared by all built-in modes. */
+    protected applyMode(envelope: Envelope, protoRegistry: ProtoRegistry): void;
     getTask(taskId: string): TaskRecord | undefined;
     isComplete(taskId: string): boolean;
     isFailed(taskId: string): boolean;

package/dist/projections/task.js

@@ -2,65 +2,36 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.TaskProjection = void 0;
 const constants_1 = require("../constants");
-const logging_1 = require("../logging");
-class TaskProjection {
+const base_1 = require("./base");
+class TaskProjection extends base_1.BaseProjection {
+    mode = constants_1.MODE_TASK;
     tasks = new Map();
     updates = [];
     completions = [];
     failures = [];
-    /**
-     * The session's accepted history, one envelope per unique `message_id`. See
-     * `BaseProjection.transcript` (`src/projections/base.ts`) for the full
-     * redelivery-idempotence contract (RFC-MACP-0006 §3.2); duplicated here
-     * only as a one-line pointer.
-     */
-    transcript = [];
-    /**
-     * Cardinality anomalies recorded while replaying this projection's accepted
-     * transcript. See `BaseProjection.anomalies` (`src/projections/base.ts`)
-     * for the canonical description; duplicated here only as a one-line
-     * pointer. No built-in detection populates this for Task mode.
-     */
-    anomalies = [];
     phase = 'Pending';
-    commitment;
-    /**
-     * `message_id`s already applied to this projection. See
-     * `BaseProjection.seenMessageIds` (`src/projections/base.ts`) for the full
-     * redelivery-idempotence rationale (RFC-MACP-0006 §3.2); duplicated here
-     * only as a one-line pointer.
-     */
-    seenMessageIds = new Set();
     /**
-     * Apply one envelope to this projection's in-process state.
+     * The **session-level** active assignment: who currently holds the session's
+     * single assignee slot, and which `task_id` they took it on.
      *
-     * Input contract: **accepted-only**, caller-maintained (`Envelope` carries
-     * no acceptance marker). Canonical source: `schemas/conformance/README.md`
-     * "Notes:", RFC-MACP-0007 §5.3, RFC-MACP-0011 §5. Full rationale and failure
-     * mode are documented once, on `BaseProjection.applyEnvelope`
-     * (`src/projections/base.ts`), and duplicated here only as a one-line
-     * pointer so six independent copies of the same prose cannot drift.
+     * RFC-MACP-0009 §5 rule 3 (`:69`): "Only one assignee may become active for
+     * the Session in base v1." The constraint is scoped to the *Session*, not to
+     * a `task_id` — rule 1 (`:67`) separately caps a v1 session at one
+     * `TaskRequest`, so in a conforming transcript the two scopes coincide, but
+     * an unfiltered transcript carrying two `TaskRequest`s must not be able to
+     * hand out two active assignees. That is why this is one field on the
+     * projection rather than a per-`TaskRecord` flag (issue #71).
      *
-     * Redelivery idempotence: a redelivered envelope (same `message_id`) is a
-     * non-event — not appended to `transcript`, not passed to the `switch`.
-     * See `BaseProjection.applyEnvelope` for the full RFC-MACP-0006 §3.2
-     * citation; duplicated here only as a one-line pointer.
+     * `sender` is the envelope sender, not `TaskAcceptPayload.assignee`, to
+     * mirror the reference runtime: `macp-runtime`
+     * `crates/macp-modes/src/mode/task.rs:211` sets `state.active_assignee =
+     * Some(env.sender)` after rejecting any payload whose `assignee` disagrees
+     * with the sender (`:205-207`). `taskId` is retained so a reject can clear
+     * the right `TaskRecord.assignee` even on a multi-task transcript.
      */
-    applyEnvelope(envelope, protoRegistry) {
-        if (envelope.mode !== constants_1.MODE_TASK)
-            return;
-        if (envelope.messageId) {
-            if (this.seenMessageIds.has(envelope.messageId)) {
-                logging_1.logger.debug('projection redelivery ignored', {
-                    messageId: envelope.messageId,
-                    mode: envelope.mode,
-                    messageType: envelope.messageType,
-                });
-                return;
-            }
-            this.seenMessageIds.add(envelope.messageId);
-        }
-        this.transcript.push(envelope);
+    activeAssignment;
+    /** Handle a Task-mode envelope. See `BaseProjection.applyEnvelope` for the accepted-only input contract and redelivery/rollback semantics shared by all built-in modes. */
+    applyMode(envelope, protoRegistry) {
         const payload = protoRegistry.decodeKnownPayload(envelope.mode, envelope.messageType, envelope.payload);
         switch (envelope.messageType) {
             case 'TaskRequest': {
@@ -81,46 +52,72 @@ class TaskProjection {
             case 'TaskAccept': {
                 const record = payload;
                 const task = this.tasks.get(record.taskId);
-                // RFC-MACP-0009 §5 rules 3/3a (`:69-71`): "Only one assignee may
+                // RFC-MACP-0009 §5 rules 3/3a (`:69-70`): "Only one assignee may
                 // become active for the Session in base v1. The first accepted
                 // `TaskAccept` from any eligible participant designates that
                 // participant as the active assignee. Subsequent `TaskAccept`
                 // messages for the same session MUST be rejected if an active
                 // assignee is already designated." A conforming runtime rejects the
-                // second `TaskAccept` before it reaches accepted history; this guard
-                // makes the projection first-accept-wins too, so a rogue second one
-                // (e.g. an unfiltered transcript) cannot silently reassign the task.
+                // second `TaskAccept` before it reaches accepted history
+                // (`macp-runtime` `crates/macp-modes/src/mode/task.rs:184-186`); this
+                // guard makes the projection first-accept-wins too, so a rogue second
+                // one (e.g. an unfiltered transcript) cannot silently reassign.
+                //
+                // The guard is keyed on the SESSION slot (`activeAssignment`), not on
+                // `task.assignee`, because rule 3's scope is the Session (issue #71).
+                // Two `TaskRequest`s in one transcript therefore share one assignee
+                // slot, matching the runtime, whose `TaskState` holds a single
+                // `active_assignee` (`task.rs:70`) alongside a single `task`.
                 //
-                // Rule 3c's policy-gated reassignment path (`allow_reassignment_on_reject`,
-                // RFC-MACP-0012 `:135`) is deliberately NOT modelled here:
-                // `TaskProjection` has no session-policy input today, and rule 3b
-                // makes an unconditional reassignment wrong by default ("`TaskAccept`
-                // is irrevocable unless policy explicitly permits reassignment").
-                // Plumbing policy into this projection needs its own decision (see
-                // plans/cross-repo/macp-sdk-typescript-conformance-and-transport.md,
-                // Phase 3 open question 4) before that path can be implemented.
+                // Rule 3c's policy-gated reassignment (`allow_reassignment_on_reject`,
+                // RFC-MACP-0012 `:135`) is reachable here via the `TaskReject` case
+                // below, which frees the slot — see its comment for why that needs no
+                // policy input.
                 //
                 // An anomaly would be recorded when this guard discards a second
                 // `TaskAccept`, but `ProjectionAnomalyKind` (`base.ts:8-9`) is
                 // deliberately frozen pending cross-SDK agreement with
                 // macp-sdk-python.
-                if (task && task.assignee === undefined) {
+                if (task && this.activeAssignment === undefined) {
                     task.assignee = record.assignee;
                     task.status = 'accepted';
+                    this.activeAssignment = { sender: envelope.sender, taskId: record.taskId };
+                    this.phase = 'InProgress';
                 }
-                this.phase = 'InProgress';
                 break;
             }
             case 'TaskReject': {
                 const record = payload;
                 const task = this.tasks.get(record.taskId);
-                // Deliberately does not clear `task.assignee`: rule 3c's
-                // policy-gated reassignment path is not modelled here (see the
-                // `TaskAccept` case above), so `assignee` is treated as sticky once
-                // set, per rule 3b's default ("irrevocable unless policy explicitly
-                // permits reassignment").
                 if (task)
                     task.status = 'rejected';
+                // RFC-MACP-0009 §5 rule 3c (`:72`): "When policy sets
+                // `allow_reassignment_on_reject: true` and the active assignee sends
+                // `TaskReject`, the session returns to the pre-assignment state. Other
+                // eligible participants MAY then send `TaskAccept` for the same
+                // `task_id`." Mirrors `macp-runtime`
+                // `crates/macp-modes/src/mode/task.rs:257-260`, which clears
+                // `active_assignee` only when the ACTIVE assignee is the rejecter —
+                // a reject from anyone else never frees the slot (`task.rs:241-244`
+                // rejects it as `InvalidPayload`).
+                //
+                // Deliberately NOT gated on the session policy, and it does not need
+                // to be. The runtime gates the reassignment twice — it denies the
+                // active assignee's `TaskReject` (`task.rs:223-239`) and the follow-up
+                // `TaskAccept` (`task.rs:187-204`) with `PolicyDenied` when
+                // `allow_reassignment_on_reject` is false — and a projection is a view
+                // of history the runtime ALREADY ACCEPTED (see this method's
+                // accepted-only input contract). A reassignment the runtime denied
+                // never reaches the transcript, so tracking the reject unconditionally
+                // cannot diverge from the runtime on any real transcript, and it needs
+                // no new API surface (threading a `PolicyDefinition` into the
+                // constructor would). Issue #70, option 2.
+                if (this.activeAssignment?.sender === envelope.sender) {
+                    const held = this.tasks.get(this.activeAssignment.taskId);
+                    if (held)
+                        held.assignee = undefined;
+                    this.activeAssignment = undefined;
+                }
                 break;
             }
             case 'TaskUpdate': {
@@ -153,33 +150,10 @@ class TaskProjection {
                 this.phase = 'Failed';
                 break;
             }
-            case 'Commitment': {
-                this.commitment = payload;
-                this.phase = 'Committed';
-                break;
-            }
             default:
                 break;
         }
     }
-    /**
-     * True once at least one `ProjectionAnomaly` has been recorded. See
-     * `BaseProjection.hasAnomalies` (`src/projections/base.ts`) for the
-     * canonical description; duplicated here only as a one-line pointer.
-     */
-    get hasAnomalies() {
-        return this.anomalies.length > 0;
-    }
-    get isCommitted() {
-        return this.commitment !== undefined;
-    }
-    get isPositiveOutcome() {
-        if (!this.commitment)
-            return undefined;
-        const val = this.commitment.outcomePositive ??
-            this.commitment.outcome_positive;
-        return val !== undefined ? Boolean(val) : true;
-    }
     getTask(taskId) {
         return this.tasks.get(taskId);
     }

package/dist/proto-registry.d.ts

@@ -10,11 +10,25 @@ export declare class ProtoRegistry {
     /**
      * Decode an `ext.multi_round.v1` `Contribute` payload, accepting both wire
      * formats: legacy JSON (`{"value":"..."}`, still replayed verbatim from
-     * pre-proto histories) and canonical protobuf (`ContributePayload`). JSON is
-     * tried first — mirroring the runtime's permanent decode order — and the two
-     * encodings are disjoint on their first byte (`{` = 0x7b vs proto field-1
-     * tag 0x0A), so a canonical proto payload never mis-parses as JSON and vice
-     * versa. Both normalize to `{ value: string }`.
+     * pre-proto histories) and canonical protobuf (`ContributePayload`). Both
+     * normalize to `{ value: string }`.
+     *
+     * Parse-then-fallback (issue #93), not a first-byte shortcut: JSON is always
+     * attempted first, and only a `JSON.parse` failure falls through to
+     * protobuf. A first-byte check (`{` = 0x7b vs proto field-1 tag 0x0A) does
+     * not generalize — e.g. legacy JSON with leading whitespace has neither byte
+     * first, and used to reach `decodeMessage` and throw. Parity with
+     * `macp-sdk-python`'s `_decode_json_first_then_proto`, which has always
+     * worked this way. Safe because a canonical proto payload's bytes are
+     * essentially never also syntactically valid JSON.
+     *
+     * An empty payload falls through the same path: `JSON.parse('')` throws, so
+     * it reaches `decodeMessage` on zero bytes, which yields `{}` (proto3
+     * defaults) rather than a decode error. This SDK's decode layer is
+     * observational, not an acceptance gate — whether an empty `Contribute`
+     * should be rejected is a runtime-acceptance question (tracked cross-repo,
+     * `contribute_acceptance.empty_payload` in `schemas/parity/contract.json`,
+     * currently `macp-runtime`-only), not something this method decides.
      */
     private decodeMultiRoundContribute;
     private lookupType;

package/dist/proto-registry.js

@@ -169,26 +169,34 @@ class ProtoRegistry {
     /**
      * Decode an `ext.multi_round.v1` `Contribute` payload, accepting both wire
      * formats: legacy JSON (`{"value":"..."}`, still replayed verbatim from
-     * pre-proto histories) and canonical protobuf (`ContributePayload`). JSON is
-     * tried first — mirroring the runtime's permanent decode order — and the two
-     * encodings are disjoint on their first byte (`{` = 0x7b vs proto field-1
-     * tag 0x0A), so a canonical proto payload never mis-parses as JSON and vice
-     * versa. Both normalize to `{ value: string }`.
+     * pre-proto histories) and canonical protobuf (`ContributePayload`). Both
+     * normalize to `{ value: string }`.
+     *
+     * Parse-then-fallback (issue #93), not a first-byte shortcut: JSON is always
+     * attempted first, and only a `JSON.parse` failure falls through to
+     * protobuf. A first-byte check (`{` = 0x7b vs proto field-1 tag 0x0A) does
+     * not generalize — e.g. legacy JSON with leading whitespace has neither byte
+     * first, and used to reach `decodeMessage` and throw. Parity with
+     * `macp-sdk-python`'s `_decode_json_first_then_proto`, which has always
+     * worked this way. Safe because a canonical proto payload's bytes are
+     * essentially never also syntactically valid JSON.
+     *
+     * An empty payload falls through the same path: `JSON.parse('')` throws, so
+     * it reaches `decodeMessage` on zero bytes, which yields `{}` (proto3
+     * defaults) rather than a decode error. This SDK's decode layer is
+     * observational, not an acceptance gate — whether an empty `Contribute`
+     * should be rejected is a runtime-acceptance question (tracked cross-repo,
+     * `contribute_acceptance.empty_payload` in `schemas/parity/contract.json`,
+     * currently `macp-runtime`-only), not something this method decides.
      */
     decodeMultiRoundContribute(payload) {
-        if (!payload.length)
+        try {
+            const parsed = JSON.parse(payload.toString('utf8'));
+            return { value: typeof parsed.value === 'string' ? parsed.value : String(parsed.value ?? '') };
+        }
+        catch {
             return this.decodeMessage(MULTI_ROUND_CONTRIBUTE, payload);
-        if (payload[0] === 0x7b) {
-            // Leading `{` — legacy JSON. Parse and normalize to { value }.
-            try {
-                const parsed = JSON.parse(payload.toString('utf8'));
-                return { value: typeof parsed.value === 'string' ? parsed.value : String(parsed.value ?? '') };
-            }
-            catch {
-                // Not valid JSON despite the leading brace — fall through to protobuf.
-            }
         }
-        return this.decodeMessage(MULTI_ROUND_CONTRIBUTE, payload);
     }
     lookupType(typeName) {
         const lookedUp = this.root.lookupType(typeName);

package/dist/validation.d.ts

@@ -5,6 +5,26 @@ export declare function validateConfidence(value: number): void;
 export declare function validateSeverity(value: string): string;
 export declare function validateParticipantCount(count: number): void;
 export declare function validateSignalType(signalType: string, data?: Buffer | Uint8Array): void;
+/**
+ * Validate the `Progress` scope pairing (RFC-MACP-0001 §6).
+ *
+ * `Progress` is legal in exactly two shapes — ambient (`sessionId` and `mode`
+ * both empty) or session-scoped (both non-empty). An envelope with exactly one
+ * of the two empty is a mixed shape that the runtime rejects with
+ * `INVALID_ENVELOPE`; raising here names the mismatched field instead.
+ *
+ * Unlike Signals, `Progress` is *not* required to be ambient — this is a
+ * tri-state rule, so neither field may be inferred from the other.
+ *
+ * The emptiness test deliberately mirrors `macp-runtime`'s
+ * `validate_envelope_shape` **exactly**, including its asymmetry: `sessionId`
+ * is compared raw while `mode` is trimmed first. Mirroring rather than
+ * normalising is the only choice under which the SDK neither accepts a shape
+ * the runtime rejects nor rejects one it accepts. Concretely, a
+ * whitespace-only `mode` alongside an empty `sessionId` is ambient to the
+ * runtime, so it stays ambient here.
+ */
+export declare function validateProgressScope(sessionId: string, mode: string): void;
 export declare function validateTtlMs(ttlMs: number): void;
 export declare function validateMaxSuspendMs(maxSuspendMs: number): void;
 export declare function validateParticipants(participants: string[]): void;

package/dist/validation.js

@@ -7,6 +7,7 @@ exports.validateConfidence = validateConfidence;
 exports.validateSeverity = validateSeverity;
 exports.validateParticipantCount = validateParticipantCount;
 exports.validateSignalType = validateSignalType;
+exports.validateProgressScope = validateProgressScope;
 exports.validateTtlMs = validateTtlMs;
 exports.validateMaxSuspendMs = validateMaxSuspendMs;
 exports.validateParticipants = validateParticipants;
@@ -61,6 +62,37 @@ function validateSignalType(signalType, data) {
         throw new errors_1.MacpSessionError('signalType must be non-empty when data is present');
     }
 }
+/**
+ * Validate the `Progress` scope pairing (RFC-MACP-0001 §6).
+ *
+ * `Progress` is legal in exactly two shapes — ambient (`sessionId` and `mode`
+ * both empty) or session-scoped (both non-empty). An envelope with exactly one
+ * of the two empty is a mixed shape that the runtime rejects with
+ * `INVALID_ENVELOPE`; raising here names the mismatched field instead.
+ *
+ * Unlike Signals, `Progress` is *not* required to be ambient — this is a
+ * tri-state rule, so neither field may be inferred from the other.
+ *
+ * The emptiness test deliberately mirrors `macp-runtime`'s
+ * `validate_envelope_shape` **exactly**, including its asymmetry: `sessionId`
+ * is compared raw while `mode` is trimmed first. Mirroring rather than
+ * normalising is the only choice under which the SDK neither accepts a shape
+ * the runtime rejects nor rejects one it accepts. Concretely, a
+ * whitespace-only `mode` alongside an empty `sessionId` is ambient to the
+ * runtime, so it stays ambient here.
+ */
+function validateProgressScope(sessionId, mode) {
+    const sessionIdEmpty = sessionId === '';
+    const modeEmpty = mode.trim() === '';
+    if (sessionIdEmpty === modeEmpty)
+        return;
+    const detail = sessionIdEmpty
+        ? `mode is ${JSON.stringify(mode)} but sessionId is empty`
+        : `sessionId is ${JSON.stringify(sessionId)} but mode is empty`;
+    throw new errors_1.MacpSessionError(`Progress must be either ambient (sessionId and mode both empty) or session-scoped ` +
+        `(both non-empty), but ${detail} (RFC-MACP-0001 §6). ` +
+        'Pass both fields for a session-scoped Progress, or neither for an ambient one.');
+}
 const MAX_TTL_MS = 86_400_000; // 24 hours
 function validateTtlMs(ttlMs) {
     if (!Number.isFinite(ttlMs) || ttlMs < 1 || ttlMs > MAX_TTL_MS) {

package/dist/version.d.ts

@@ -4,4 +4,4 @@
  * Kept in sync with package.json by release-please (see the
  * `x-release-please-version` annotation).
  */
-export declare const VERSION = "0.9.0";
+export declare const VERSION = "0.11.0";

package/dist/version.js

@@ -7,4 +7,4 @@ exports.VERSION = void 0;
  * Kept in sync with package.json by release-please (see the
  * `x-release-please-version` annotation).
  */
-exports.VERSION = '0.9.0'; // x-release-please-version
+exports.VERSION = '0.11.0'; // x-release-please-version

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "macp-sdk-typescript",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "TypeScript SDK for the MACP Rust runtime",
   "license": "Apache-2.0",
   "type": "commonjs",
@@ -55,18 +55,18 @@
   "dependencies": {
     "@grpc/grpc-js": "^1.14.3",
     "@grpc/proto-loader": "^0.8.0",
-    "@multiagentcoordinationprotocol/proto": "^0.1.9",
+    "@multiagentcoordinationprotocol/proto": "^0.1.10",
     "protobufjs": "^8.6.5"
   },
   "devDependencies": {
     "@types/node": "^26.4.0",
     "@typescript-eslint/eslint-plugin": "^8.68.0",
     "@typescript-eslint/parser": "^8.68.0",
-    "@vitest/coverage-v8": "^4.1.11",
+    "@vitest/coverage-v8": "^5.0.0",
     "eslint": "^10.9.1",
     "prettier": "^3.0.0",
     "tsx": "^4.21.0",
     "typescript": "^6.0.3",
-    "vitest": "^4.1.11"
+    "vitest": "^5.0.0"
   }
 }