macp-sdk-typescript 0.8.0 → 0.10.0

package/CHANGELOG.md

@@ -4,6 +4,102 @@ All notable changes to `macp-sdk-typescript` are documented here. The format
 follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and the
 project uses [Semantic Versioning](https://semver.org/).
 
+## [0.10.0](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/compare/v0.9.0...v0.10.0) (2026-09-01)
+
+
+### ⚠ BREAKING CHANGES
+
+* `client.sendProgress()` now throws `MacpSessionError` when exactly one of `sessionId`/`mode` is supplied. Such calls used to succeed against a runtime that had the symmetric gap; as of macp-runtime PR #137 they are rejected with `INVALID_ENVELOPE`. Pass both fields for a session-scoped Progress, or neither for an ambient one.
+* **projections:** `TaskProjection` assignee semantics changed twice. (1) The first-accept-wins guard is now per-session, not per-`task_id`: on a transcript with two `TaskRequest`s, only the first `TaskAccept` assigns — the second task keeps `assignee === undefined` and `status === 'requested'`, where it previously got its own assignee. A `TaskAccept` the guard discards also no longer sets `phase = 'InProgress'`. (2) `TaskAccept` is no longer sticky forever: a `TaskReject` from the active assignee clears `assignee` back to `undefined`, so code reading `getTask(id).assignee` after a reject now sees `undefined` (or the reassigned participant) rather than the participant who rejected.
+
+### Bug Fixes
+
+* **projections:** scope the Task assignee slot to the session and free it on reject ([#75](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/75)) ([f7841a9](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/commit/f7841a96d120b3fc55effdfabf63a2d72f431081)), closes [#59](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/59) [#60](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/60) [#70](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/70) [#71](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/71)
+* reject mixed ambient/session-scoped Progress envelopes ([#76](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/76)) ([a9e00e3](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/commit/a9e00e370b7a4bf08d09190e8b75a12d221319f8))
+
+## [0.9.0](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/compare/v0.8.0...v0.9.0) (2026-09-01)
+
+
+### ⚠ BREAKING CHANGES
+
+* **projections:** ProposalProjection.isAccepted()/acceptedProposal(), TaskProjection's `assignee` field, and HandoffProjection's `status` field can now derive different values than before for a transcript containing the message sequences described above. Conforming transcripts (no superseded accept, no second TaskAccept/contradictory handoff accept-decline) are unaffected.
+
+### Bug Fixes
+
+* **agent:** don't count an envelope into the resume cursor until it's asked for again ([#72](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/72)) ([f1b7015](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/commit/f1b70155cb3293bc7f36c0389cbf880359a01e58)), closes [#66](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/66)
+* **agent:** resume GrpcTransportAdapter from its own cursor, and count distinct envelopes ([#65](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/65)) ([7535763](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/commit/75357632351addde3a32a61b1200e823f2ef70da))
+* **projections:** enforce cardinality rules issues [#59](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/59)/[#60](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/60) said didn't exist ([#68](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/issues/68)) ([956d881](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/commit/956d881e19591bcd9a04c6496bff07213d1ee6d3))
+
+## [Unreleased]
+
+### Fixed
+
+- **BREAKING: four projection sites now enforce the cardinality rule their
+  governing RFC section actually states, instead of last-write-wins.**
+  Issues #59 and #60 argued that no cardinality/ordering site in the
+  built-in projections had a normative rule behind it; a full re-read of the
+  four mode RFCs plus RFC-MACP-0001 found governing rules for five of the
+  ten sites they raised, three of which were shipped conformance
+  violations:
+  - `ProposalProjection` (breaking): a later `Accept` from a participant now
+    supersedes their earlier one (RFC-MACP-0008 §5 rule 5, `:70`), so
+    `isAccepted` and `acceptedProposal()` read the live acceptance set
+    instead of raw accept history. Previously `acceptedProposal()` could
+    return `undefined` after a legal re-accept, where the RFC's
+    determinism clause (§7, `:89`) makes the accepted proposal unambiguous.
+  - `TaskProjection` (breaking): the first accepted `TaskAccept` now wins —
+    a later `TaskAccept` for the same task no longer overwrites `assignee`
+    (RFC-MACP-0009 §5 rules 3/3a, `:69-71`). The policy-gated reassignment
+    path (rule 3c) is intentionally not modelled yet; `TaskProjection` has
+    no session-policy input.
+  - `HandoffProjection` (breaking): a `handoff_id` now settles (`offered` →
+    `accepted`/`declined`) exactly once — a later contradictory
+    `HandoffAccept`/`HandoffDecline` for an already-settled `handoff_id`,
+    or for a `handoff_id` that was never offered, is ignored in both
+    directions and can no longer mutate `phase` (RFC-MACP-0010 §5 rule 2
+    `:65`, rule 4 `:68`, §5.1(4) `:113-116`).
+  - `DecisionProjection` (not breaking for conforming callers): `phase` no
+    longer regresses out of `'Committed'` if a `Vote` is replayed after a
+    `Commitment` — such a message cannot legally exist in accepted history
+    under a conforming runtime (RFC-MACP-0001 §7.2 `:218`, §7.3
+    `:240`/`:249`), but a caller violating the accepted-only contract no
+    longer corrupts `phase` if it happens.
+
+  `ProposalProjection.isAccepted()`/`acceptedProposal()`, `TaskProjection`'s
+  `assignee` field, and `HandoffProjection`'s `status`/`phase` can now
+  derive different values than before for a transcript containing the
+  message sequences described above — existing callers reading those
+  surfaces should treat this as a breaking change. Conforming transcripts
+  (no superseded accept, no second `TaskAccept`, no contradictory or
+  unknown-`handoff_id` handoff accept/decline) are unaffected.
+
+  Three other sites raised by #59 (Decision `Evaluation`/`Objection`
+  cardinality, Task `TaskUpdate` accumulation) were confirmed to be silent
+  *coherently* and are unchanged. `TaskComplete`/`TaskFail` cardinality is
+  genuinely ambiguous in RFC-MACP-0009 and is tracked as an upstream spec
+  question rather than an SDK change.
+
+### Changed
+
+- **`GrpcTransportAdapter` resumes instead of replaying on a second `start()`.**
+  The adapter now calls `sendSubscribe(sessionId, this.lastSequence)` instead of
+  always subscribing from `0`, so a caller that `stop()`s and re-`start()`s a
+  reused adapter — the only reachable "reconnect" in this SDK; there is no
+  built-in retry loop — no longer replays the entire session history. Requires
+  `macp-runtime` ≥ 0.5.0 for the `after_sequence` ordinal contract
+  (RFC-MACP-0006 §3.2); older runtimes compared it inclusively against a raw
+  log index. `lastSequence` itself is corrected in the same change to count
+  **distinct** accepted envelopes (keyed on `message_id`) instead of raw
+  delivery events — passing the old, uncorrected counter as a resume cursor
+  would have silently skipped history on resume (RFC-MACP-0006 §3.2
+  Redelivery). Anyone relying on a reused adapter's second `start()` to rebuild
+  a *fresh* projection from full history will now see only the envelopes
+  accepted since the first pass ended; open a new `GrpcTransportAdapter` (or a
+  raw `MacpStream` with `sendSubscribe(sessionId, 0)`) for a full replay.
+- `MacpStream.sendSubscribe`'s docblock no longer claims `IncomingMessage.seq`
+  is the RFC-MACP-0006 ordinal — `seq` is a 0-based delivery index that
+  advances on redelivery, unlike the ordinal.
+
 ## [0.8.0](https://github.com/multiagentcoordinationprotocol/macp-sdk-typescript/compare/v0.7.1...v0.8.0) (2026-08-31)
 
 

package/README.md

@@ -367,7 +367,7 @@ await stream.sendSubscribe(sessionId);            // full replay then live
 await stream.sendSubscribe(sessionId, lastSeq);    // resume from cursor
 ```
 
-The agent framework's `GrpcTransportAdapter` calls this for you on start, so non-initiator agents see `SessionStart` regardless of join order.
+The agent framework's `GrpcTransportAdapter` calls this for you on start, so non-initiator agents see `SessionStart` regardless of join order — and it passes its own resume cursor on a second `start()` (after a `stop()`), so that call resumes rather than replaying the whole session again.
 
 ### Registry & Root Watchers
 

package/dist/agent/transports.d.ts

@@ -12,14 +12,39 @@ export declare class GrpcTransportAdapter implements TransportAdapter {
     private stream;
     private seq;
     private delivered;
+    /**
+     * `message_id`s already counted into `delivered`, so the resume cursor
+     * advances once per distinct accepted envelope rather than once per raw
+     * delivery (RFC-MACP-0006 §3.2 Redelivery). Deliberately unbounded, for the
+     * same reason `BaseProjection` leaves its own copy of this set unbounded
+     * (`src/projections/base.ts:118-129`): this set is strictly dominated by
+     * memory this SDK already commits to per session — a `Participant` using
+     * this adapter also holds a `BaseProjection` with an identical
+     * `message_id` set *plus* a full `transcript` of every envelope, payload
+     * bytes included. The runtime keeps an unbounded per-session dedup set of
+     * its own regardless of what any client does
+     * (`macp-runtime/crates/macp-modes/src/step.rs:48/:89`, field declared at
+     * `macp-runtime/crates/macp-core/src/session.rs:69`), and sessions are
+     * TTL-bounded by protocol.
+     */
+    private readonly seenMessageIds;
     constructor(client: MacpClient, sessionId: string, auth?: AuthConfig | undefined);
     /**
      * The server passive-subscribe ordinal of the last delivered envelope (the
-     * 1-based count of accepted envelopes delivered on this stream, RFC-MACP-0006
-     * §3.2). `0` before anything is delivered. Pass this as `afterSequence` to
-     * `MacpStream.sendSubscribe` on a reconnect to resume exactly-once — ordinals
-     * are stable across compaction/restart. Distinct from `IncomingMessage.seq`,
-     * which is a client-local 0-based delivery index.
+     * 1-based count of *distinct* accepted envelopes delivered on this stream,
+     * RFC-MACP-0006 §3.2). `0` before anything is delivered. `start()` passes
+     * this value as `afterSequence` to `MacpStream.sendSubscribe` itself, so a
+     * caller that `stop()`s and calls `start()` again (the only reachable
+     * "reconnect" in this SDK — there is no built-in retry loop) resumes
+     * rather than replays the whole session. Ordinals are stable across
+     * compaction/restart. Counts distinct `message_id`s, never raw delivery
+     * events: RFC-MACP-0006 §3.2 Redelivery requires that "a redelivery MUST
+     * NOT advance the client's sequence position; only a distinct accepted
+     * envelope does," and a client that counts raw deliveries "arrives at a
+     * position ahead of the true one, and its next resume silently skips
+     * history." Distinct from `IncomingMessage.seq`, which is a client-local
+     * 0-based delivery index that advances on every delivery, redeliveries
+     * included.
      */
     get lastSequence(): number;
     start(): AsyncIterable<IncomingMessage>;

package/dist/agent/transports.js

@@ -19,6 +19,22 @@ class GrpcTransportAdapter {
     stream = null;
     seq = 0;
     delivered = 0;
+    /**
+     * `message_id`s already counted into `delivered`, so the resume cursor
+     * advances once per distinct accepted envelope rather than once per raw
+     * delivery (RFC-MACP-0006 §3.2 Redelivery). Deliberately unbounded, for the
+     * same reason `BaseProjection` leaves its own copy of this set unbounded
+     * (`src/projections/base.ts:118-129`): this set is strictly dominated by
+     * memory this SDK already commits to per session — a `Participant` using
+     * this adapter also holds a `BaseProjection` with an identical
+     * `message_id` set *plus* a full `transcript` of every envelope, payload
+     * bytes included. The runtime keeps an unbounded per-session dedup set of
+     * its own regardless of what any client does
+     * (`macp-runtime/crates/macp-modes/src/step.rs:48/:89`, field declared at
+     * `macp-runtime/crates/macp-core/src/session.rs:69`), and sessions are
+     * TTL-bounded by protocol.
+     */
+    seenMessageIds = new Set();
     constructor(client, sessionId, auth) {
         this.client = client;
         this.sessionId = sessionId;
@@ -26,27 +42,92 @@ class GrpcTransportAdapter {
     }
     /**
      * The server passive-subscribe ordinal of the last delivered envelope (the
-     * 1-based count of accepted envelopes delivered on this stream, RFC-MACP-0006
-     * §3.2). `0` before anything is delivered. Pass this as `afterSequence` to
-     * `MacpStream.sendSubscribe` on a reconnect to resume exactly-once — ordinals
-     * are stable across compaction/restart. Distinct from `IncomingMessage.seq`,
-     * which is a client-local 0-based delivery index.
+     * 1-based count of *distinct* accepted envelopes delivered on this stream,
+     * RFC-MACP-0006 §3.2). `0` before anything is delivered. `start()` passes
+     * this value as `afterSequence` to `MacpStream.sendSubscribe` itself, so a
+     * caller that `stop()`s and calls `start()` again (the only reachable
+     * "reconnect" in this SDK — there is no built-in retry loop) resumes
+     * rather than replays the whole session. Ordinals are stable across
+     * compaction/restart. Counts distinct `message_id`s, never raw delivery
+     * events: RFC-MACP-0006 §3.2 Redelivery requires that "a redelivery MUST
+     * NOT advance the client's sequence position; only a distinct accepted
+     * envelope does," and a client that counts raw deliveries "arrives at a
+     * position ahead of the true one, and its next resume silently skips
+     * history." Distinct from `IncomingMessage.seq`, which is a client-local
+     * 0-based delivery index that advances on every delivery, redeliveries
+     * included.
      */
     get lastSequence() {
         return this.delivered;
     }
     async *start() {
+        // A prior stream from an earlier start() (without an intervening stop())
+        // must not keep feeding this adapter's counter — two live generators
+        // would both advance `delivered` from two differently-positioned
+        // replays. `MacpStream.close()` is `this.call.end()` (`src/client.ts:223-227`),
+        // a write-side half-close — it does not itself force the server to stop
+        // pushing. It is enough here because macp-runtime's StreamSession loop
+        // reads the resulting end-of-request-stream as `StreamAction::ClientDone`,
+        // whose arm drains any already-buffered envelopes once and then breaks,
+        // ending that stream's response side too
+        // (macp-runtime/src/server.rs:654-666). Close it before opening the new
+        // one so re-entrant start() and stop()-then-start() behave identically.
+        if (this.stream) {
+            this.stream.close();
+            this.stream = null;
+        }
         this.stream = this.client.openStream({ auth: this.auth });
-        // RFC-MACP-0006-A1: Subscribe to the session with history replay.
-        // The runtime replays accepted envelopes then switches to live broadcast.
-        // This ensures non-initiator agents receive the SessionStart + Proposal
-        // regardless of spawn order or connection timing.
-        await this.stream.sendSubscribe(this.sessionId);
+        // RFC-MACP-0006 §3.2: subscribe to the session, resuming from this
+        // adapter's own cursor. `this.delivered` is 0 before anything has been
+        // delivered, by construction, and `afterSequence = 0` is normatively
+        // "replay from the session's first accepted envelope" — so the first
+        // subscribe and every later one (e.g. after stop()+start()) are the same
+        // expression. There is no separate first-subscribe/reconnect branch to
+        // keep in sync with the counter.
+        await this.stream.sendSubscribe(this.sessionId, this.delivered);
         for await (const envelope of this.stream.responses()) {
             if (envelope.sessionId !== this.sessionId)
                 continue;
-            this.delivered++;
-            yield normalizeEnvelope(envelope, (mode, mt, p) => this.client.protoRegistry.decodeKnownPayload(mode, mt, p), this.seq++);
+            // Count this envelope into the resume cursor only *after* the
+            // consumer has come back for more, not when it is handed off. `yield`
+            // suspends here until the consumer's `for await` either calls
+            // `.next()` again (it took this envelope and kept iterating — the
+            // code below runs) or closes the iterator via `break`/`return`/throw
+            // (e.g. `Participant.run()` observing `!this.running` and breaking
+            // out of its loop without processing this envelope). In the latter
+            // case `.return()` on this generator resumes at this `yield` as if a
+            // `return` had been written here, so nothing below it runs: the
+            // cursor is never advanced past an envelope the consumer never
+            // actually took past the loop boundary, and the next `start()`
+            // redelivers it instead of silently skipping it. See #66 — counting
+            // before yielding let a stop-mid-stream permanently drop an envelope
+            // once #65 made the resume cursor authoritative.
+            const message = normalizeEnvelope(envelope, (mode, mt, p) => this.client.protoRegistry.decodeKnownPayload(mode, mt, p), this.seq++);
+            yield message;
+            // RFC-MACP-0006 §3.2 Redelivery: a redelivery MUST NOT advance the
+            // resume cursor, and a consumer that accumulates state per envelope
+            // MUST be idempotent w.r.t. `message_id`. An empty/absent messageId
+            // has no identity to dedup on and increments unconditionally — the
+            // same carve-out the projection guard documents at
+            // `src/projections/base.ts:224-227`, so the two dedup sites read the
+            // same way. In practice the `else` below can never run against a
+            // conformant runtime: `validate_envelope_shape` rejects any envelope
+            // with an empty `message_id` as `InvalidEnvelope` before it can be
+            // accepted (`macp-runtime/src/server.rs:118`), and RFC-MACP-0001 §8.2
+            // makes `message_id` the runtime's dedup identity, so no accepted
+            // envelope in any session history can carry one. The branch stays
+            // anyway — it costs nothing and errs toward still counting the
+            // envelope instead of silently dropping it if a non-conformant server
+            // ever sends one.
+            if (envelope.messageId) {
+                if (!this.seenMessageIds.has(envelope.messageId)) {
+                    this.seenMessageIds.add(envelope.messageId);
+                    this.delivered++;
+                }
+            }
+            else {
+                this.delivered++;
+            }
         }
     }
     async stop() {

package/dist/client.d.ts

@@ -48,9 +48,13 @@ export declare class MacpStream {
      *
      * `afterSequence` is the **1-based accepted-envelope ordinal**, exclusive:
      * `0` (default) replays from the very start; `k` replays envelopes with
-     * ordinal `> k`. Clients derive the ordinal by counting delivered envelopes
-     * (the Nth accepted envelope has ordinal N) — see
-     * `IncomingMessage.seq`, which is exactly this ordinal under the new contract.
+     * ordinal `> k`. Clients derive the ordinal by counting **distinct**
+     * accepted envelopes delivered, keyed on `message_id` — RFC-MACP-0006 §3.2
+     * Redelivery requires that a repeat of an already-observed envelope MUST
+     * NOT advance the count. This is **not** the same as `IncomingMessage.seq`,
+     * which is a client-local 0-based delivery index that advances on every
+     * delivery, redeliveries included; see `GrpcTransportAdapter.lastSequence`
+     * for a cursor that tracks the ordinal correctly.
      * Ordinals are stable across log compaction and runtime restart. Resuming
      * below a compacted base returns `FAILED_PRECONDITION` (inspectable via
      * `MacpTransportError.code`) rather than silently skipping history (runtime
@@ -258,6 +262,15 @@ export declare class MacpClient {
         auth?: AuthConfig;
         deadlineMs?: number;
     }): Promise<Ack>;
+    /**
+     * Send a `Progress` message.
+     *
+     * Per RFC-MACP-0001 §6, `Progress` is legal in exactly two shapes: *ambient*
+     * (`sessionId` and `mode` both omitted/empty) or *session-scoped* (both
+     * non-empty). Supplying exactly one of the two throws `MacpSessionError` —
+     * the runtime rejects that mixed envelope with `INVALID_ENVELOPE`, so this
+     * fails fast with a message naming the mismatched field.
+     */
     sendProgress(options: {
         sessionId?: string;
         mode?: string;

package/dist/client.js

@@ -160,9 +160,13 @@ class MacpStream {
      *
      * `afterSequence` is the **1-based accepted-envelope ordinal**, exclusive:
      * `0` (default) replays from the very start; `k` replays envelopes with
-     * ordinal `> k`. Clients derive the ordinal by counting delivered envelopes
-     * (the Nth accepted envelope has ordinal N) — see
-     * `IncomingMessage.seq`, which is exactly this ordinal under the new contract.
+     * ordinal `> k`. Clients derive the ordinal by counting **distinct**
+     * accepted envelopes delivered, keyed on `message_id` — RFC-MACP-0006 §3.2
+     * Redelivery requires that a repeat of an already-observed envelope MUST
+     * NOT advance the count. This is **not** the same as `IncomingMessage.seq`,
+     * which is a client-local 0-based delivery index that advances on every
+     * delivery, redeliveries included; see `GrpcTransportAdapter.lastSequence`
+     * for a cursor that tracks the ordinal correctly.
      * Ordinals are stable across log compaction and runtime restart. Resuming
      * below a compacted base returns `FAILED_PRECONDITION` (inspectable via
      * `MacpTransportError.code`) rather than silently skipping history (runtime
@@ -541,7 +545,17 @@ class MacpClient {
         });
         return this.send(envelope, { auth, deadlineMs: options.deadlineMs });
     }
+    /**
+     * Send a `Progress` message.
+     *
+     * Per RFC-MACP-0001 §6, `Progress` is legal in exactly two shapes: *ambient*
+     * (`sessionId` and `mode` both omitted/empty) or *session-scoped* (both
+     * non-empty). Supplying exactly one of the two throws `MacpSessionError` —
+     * the runtime rejects that mixed envelope with `INVALID_ENVELOPE`, so this
+     * fails fast with a message naming the mismatched field.
+     */
     async sendProgress(options) {
+        (0, validation_1.validateProgressScope)(options.sessionId ?? '', options.mode ?? '');
         const auth = this.requireAuth(options.auth);
         (0, auth_1.assertSenderMatchesIdentity)(auth, options.sender);
         const progressPayload = (0, envelope_1.buildProgressPayload)({

package/dist/projections/decision.js

@@ -109,7 +109,23 @@ class DecisionProjection {
                 }
                 bySender.set(envelope.sender, { ...record, sender: envelope.sender });
                 this.votes.set(record.proposalId, bySender);
-                this.phase = 'Voting';
+                // RFC-MACP-0001 §7.2 (`:218`): RESOLVED is terminal and sessions
+                // MUST transition monotonically w.r.t. termination — never back to
+                // OPEN/SUSPENDED. §7.3 (`:240`, restated `:249`) says a conforming
+                // runtime rejects any session-scoped message once the session is
+                // non-OPEN, so a `Vote` cannot legally follow a `Commitment` in
+                // accepted history. If one reaches here anyway (the caller violated
+                // the accepted-only contract — see `applyEnvelope`'s docblock), do
+                // not regress `phase` out of `'Committed'`. Note "phase" itself is
+                // not a normative MACP term (it appears once, in passing, at
+                // RFC-MACP-0012 `:211`); this guard is justified by session
+                // terminality, not by a phase specification. An anomaly would be
+                // recorded here too, but `ProjectionAnomalyKind` (`base.ts:8-9`) is
+                // deliberately frozen pending cross-SDK agreement with
+                // macp-sdk-python.
+                if (this.phase !== 'Committed') {
+                    this.phase = 'Voting';
+                }
                 break;
             }
             case 'Commitment': {

package/dist/projections/handoff.js

@@ -91,25 +91,61 @@ class HandoffProjection {
             case 'HandoffAccept': {
                 const record = payload;
                 const handoff = this.handoffs.get(record.handoffId);
-                if (handoff) {
+                if (!handoff) {
+                    // RFC-MACP-0010 §5 rule 2 (`:65`): "HandoffContext, HandoffAccept,
+                    // and HandoffDecline MUST reference an existing handoff_id." An
+                    // accept for an unknown/never-offered handoff_id is invalid input
+                    // (e.g. an unfiltered transcript) and MUST NOT mutate `phase` or
+                    // fabricate a handoff record. An anomaly would be recorded here,
+                    // but `ProjectionAnomalyKind` (`base.ts:8-9`) is deliberately
+                    // frozen pending cross-SDK agreement with macp-sdk-python.
+                    break;
+                }
+                // RFC-MACP-0010 §5 rule 4 (`:68`): "Once an offer has been
+                // accepted, no competing accept for that same `handoff_id` is
+                // valid." §5.1(4) (`:113-116`) settles the decline-after-accept
+                // direction too: a `handoff_id` transitions
+                // offered -> accepted | declined exactly once. Only settle if this
+                // handoff hasn't already resolved — the same shape as the
+                // HandoffContext guard just above. An anomaly would be recorded when
+                // this guard discards a competing accept, but `ProjectionAnomalyKind`
+                // (`base.ts:8-9`) is deliberately frozen pending cross-SDK agreement
+                // with macp-sdk-python.
+                if (handoff.status === 'offered' || handoff.status === 'context_sent') {
                     handoff.status = 'accepted';
                     handoff.acceptedBy = record.acceptedBy;
                     // proto3 bool defaults are materialized to `false` on decode
                     // (proto-registry), so this is always a real boolean once proto 0.1.6
                     // is loaded — `true` marks a runtime synthetic implicit accept.
                     handoff.implicit = record.implicit ?? false;
+                    this.phase = 'Accepted';
                 }
-                this.phase = 'Accepted';
                 break;
             }
             case 'HandoffDecline': {
                 const record = payload;
                 const handoff = this.handoffs.get(record.handoffId);
-                if (handoff) {
+                if (!handoff) {
+                    // RFC-MACP-0010 §5 rule 2 (`:65`): "HandoffContext, HandoffAccept,
+                    // and HandoffDecline MUST reference an existing handoff_id." A
+                    // decline for an unknown/never-offered handoff_id is invalid input
+                    // (e.g. an unfiltered transcript) and MUST NOT mutate `phase` or
+                    // fabricate a handoff record. An anomaly would be recorded here,
+                    // but `ProjectionAnomalyKind` (`base.ts:8-9`) is deliberately
+                    // frozen pending cross-SDK agreement with macp-sdk-python.
+                    break;
+                }
+                // RFC-MACP-0010 §5 rule 4 (`:68`) + §5.1(4) (`:113-116`): a
+                // `handoff_id` settles once. A decline after the handoff already
+                // settled (accepted or declined) is invalid and ignored. An anomaly
+                // would be recorded here too, but `ProjectionAnomalyKind`
+                // (`base.ts:8-9`) is deliberately frozen pending cross-SDK agreement
+                // with macp-sdk-python.
+                if (handoff.status === 'offered' || handoff.status === 'context_sent') {
                     handoff.status = 'declined';
                     handoff.declinedBy = record.declinedBy;
+                    this.phase = 'Declined';
                 }
-                this.phase = 'Declined';
                 break;
             }
             case 'Commitment': {

package/dist/projections/proposal.d.ts

@@ -25,6 +25,20 @@ export declare class ProposalProjection {
     readonly proposals: Map<string, ProposalRecord>;
     readonly accepts: ProposalAcceptRecord[];
     readonly rejections: ProposalRejectRecord[];
+    /**
+     * Each sender's current (unsuperseded) `Accept`, keyed by sender.
+     * RFC-MACP-0008 §5 rule 5 (`:70`): "A participant MAY change its
+     * acceptance target by sending a later `Accept` for a different live
+     * proposal. The latest accepted `Accept` from a participant supersedes
+     * earlier accepts from the same participant." `accepts` above retains the
+     * full append-only history (including superseded accepts) for audit
+     * purposes; `isAccepted` and `acceptedProposal` read from this map instead
+     * so they reflect the live acceptance set — required for determinism by
+     * §7 (`:89`): "Given the same accepted history and the same version-bound
+     * rules, implementations MUST derive the same live proposal set, the same
+     * acceptance set, and the same commitment eligibility."
+     */
+    private readonly latestAcceptBySender;
     /**
      * The session's accepted history, one envelope per unique `message_id`. See
      * `BaseProjection.transcript` (`src/projections/base.ts`) for the full
@@ -74,9 +88,25 @@ export declare class ProposalProjection {
     get isPositiveOutcome(): boolean | undefined;
     activeProposals(): ProposalRecord[];
     latestProposal(): ProposalRecord | undefined;
+    /**
+     * True if some participant's *current* (unsuperseded) `Accept` targets
+     * `proposalId` — RFC-MACP-0008 §5 rule 5 (`:70`). Note this reads from the
+     * live acceptance set, not from `accepts`' full history: a participant
+     * whose only accept for `proposalId` was later superseded by a re-accept
+     * of a different proposal is not counted.
+     */
     isAccepted(proposalId: string): boolean;
     isTerminallyRejected(proposalId: string): boolean;
     liveProposals(): Map<string, ProposalRecord>;
+    /**
+     * The single proposal every participant's *current* accept targets, or
+     * `undefined` if no one has an outstanding accept or outstanding accepts
+     * are split across more than one proposal. Computed from the live
+     * acceptance set (see `isAccepted`), not from `accepts`' full history — a
+     * participant who accepts `p1` and later re-accepts `p2` (RFC-MACP-0008 §5
+     * rule 5, `:70`) contributes only `p2`, so this correctly returns `p2`
+     * rather than `undefined`.
+     */
     acceptedProposal(): string | undefined;
     hasTerminalRejection(): boolean;
 }

package/dist/projections/proposal.js

@@ -7,6 +7,20 @@ class ProposalProjection {
     proposals = new Map();
     accepts = [];
     rejections = [];
+    /**
+     * Each sender's current (unsuperseded) `Accept`, keyed by sender.
+     * RFC-MACP-0008 §5 rule 5 (`:70`): "A participant MAY change its
+     * acceptance target by sending a later `Accept` for a different live
+     * proposal. The latest accepted `Accept` from a participant supersedes
+     * earlier accepts from the same participant." `accepts` above retains the
+     * full append-only history (including superseded accepts) for audit
+     * purposes; `isAccepted` and `acceptedProposal` read from this map instead
+     * so they reflect the live acceptance set — required for determinism by
+     * §7 (`:89`): "Given the same accepted history and the same version-bound
+     * rules, implementations MUST derive the same live proposal set, the same
+     * acceptance set, and the same commitment eligibility."
+     */
+    latestAcceptBySender = new Map();
     /**
      * The session's accepted history, one envelope per unique `message_id`. See
      * `BaseProjection.transcript` (`src/projections/base.ts`) for the full
@@ -88,7 +102,11 @@ class ProposalProjection {
             }
             case 'Accept': {
                 const record = payload;
-                this.accepts.push({ ...record, sender: envelope.sender });
+                const accept = { ...record, sender: envelope.sender };
+                this.accepts.push(accept);
+                // RFC-MACP-0008 §5 rule 5 (`:70`): this Accept supersedes any earlier
+                // one from the same sender for the live acceptance set.
+                this.latestAcceptBySender.set(envelope.sender, accept);
                 break;
             }
             case 'Reject': {
@@ -149,8 +167,19 @@ class ProposalProjection {
         const all = [...this.proposals.values()];
         return all[all.length - 1];
     }
+    /**
+     * True if some participant's *current* (unsuperseded) `Accept` targets
+     * `proposalId` — RFC-MACP-0008 §5 rule 5 (`:70`). Note this reads from the
+     * live acceptance set, not from `accepts`' full history: a participant
+     * whose only accept for `proposalId` was later superseded by a re-accept
+     * of a different proposal is not counted.
+     */
     isAccepted(proposalId) {
-        return this.accepts.some((a) => a.proposalId === proposalId);
+        for (const accept of this.latestAcceptBySender.values()) {
+            if (accept.proposalId === proposalId)
+                return true;
+        }
+        return false;
     }
     isTerminallyRejected(proposalId) {
         return this.rejections.some((r) => r.proposalId === proposalId && r.terminal);
@@ -163,10 +192,19 @@ class ProposalProjection {
         }
         return result;
     }
+    /**
+     * The single proposal every participant's *current* accept targets, or
+     * `undefined` if no one has an outstanding accept or outstanding accepts
+     * are split across more than one proposal. Computed from the live
+     * acceptance set (see `isAccepted`), not from `accepts`' full history — a
+     * participant who accepts `p1` and later re-accepts `p2` (RFC-MACP-0008 §5
+     * rule 5, `:70`) contributes only `p2`, so this correctly returns `p2`
+     * rather than `undefined`.
+     */
     acceptedProposal() {
-        if (this.accepts.length === 0)
+        if (this.latestAcceptBySender.size === 0)
             return undefined;
-        const ids = new Set(this.accepts.map((a) => a.proposalId));
+        const ids = new Set([...this.latestAcceptBySender.values()].map((a) => a.proposalId));
         if (ids.size === 1)
             return ids.values().next().value;
         return undefined;

package/dist/projections/task.d.ts

@@ -61,6 +61,26 @@ export declare class TaskProjection {
      * only as a one-line pointer.
      */
     private readonly seenMessageIds;
+    /**
+     * The **session-level** active assignment: who currently holds the session's
+     * single assignee slot, and which `task_id` they took it on.
+     *
+     * 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).
+     *
+     * `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.
+     */
+    private activeAssignment?;
     /**
      * Apply one envelope to this projection's in-process state.
      *

package/dist/projections/task.js

@@ -31,6 +31,26 @@ class TaskProjection {
      * only as a one-line pointer.
      */
     seenMessageIds = new Set();
+    /**
+     * The **session-level** active assignment: who currently holds the session's
+     * single assignee slot, and which `task_id` they took it on.
+     *
+     * 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).
+     *
+     * `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.
+     */
+    activeAssignment;
     /**
      * Apply one envelope to this projection's in-process state.
      *
@@ -81,11 +101,38 @@ class TaskProjection {
             case 'TaskAccept': {
                 const record = payload;
                 const task = this.tasks.get(record.taskId);
-                if (task) {
+                // 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
+                // (`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 (`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 && 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': {
@@ -93,6 +140,33 @@ class TaskProjection {
                 const task = this.tasks.get(record.taskId);
                 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': {

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.8.0";
+export declare const VERSION = "0.10.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.8.0'; // x-release-please-version
+exports.VERSION = '0.10.0'; // x-release-please-version

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "macp-sdk-typescript",
-  "version": "0.8.0",
+  "version": "0.10.0",
   "description": "TypeScript SDK for the MACP Rust runtime",
   "license": "Apache-2.0",
   "type": "commonjs",