macp-sdk-typescript 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -4,6 +4,89 @@ 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.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

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

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.js

@@ -81,7 +81,30 @@ class TaskProjection {
             case 'TaskAccept': {
                 const record = payload;
                 const task = this.tasks.get(record.taskId);
-                if (task) {
+                // RFC-MACP-0009 §5 rules 3/3a (`:69-71`): "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.
+                //
+                // 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.
+                //
+                // 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) {
                     task.assignee = record.assignee;
                     task.status = 'accepted';
                 }
@@ -91,6 +114,11 @@ class TaskProjection {
             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';
                 break;

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.9.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.9.0'; // x-release-please-version

package/package.json

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