@mininglamp-oss/cc-channel-octo 1.0.3-dev.4ca07a0 → 1.0.3-dev.4edf363

package/dist/group-md-writeback.d.ts

@@ -0,0 +1,183 @@
+/**
+ * GROUP.md write-back (P2-C): the app-layer coordinator that persists an
+ * agent-authored GROUP.md back to the server (PUT /v1/bot/groups/{groupNo}/md)
+ * via A's `updateGroupMd` client, then refreshes A's in-memory cache so the next
+ * resolve does not TTL-refetch a stale copy.
+ *
+ * Two server-contract facts (XIN-201, measured — NOT inferred) shape this:
+ *
+ *   1. content has a HARD ≤10240-byte (UTF-8) limit; the server answers an
+ *      oversized body with 400 err.server.bot_api.content_too_large. We reject
+ *      locally BEFORE the PUT so a too-large write never reaches the server.
+ *
+ *   2. `version` is a server-side monotonic counter and the PUT does NOT do
+ *      compare-and-swap (last-write-wins, no CAS). Concurrent writers therefore
+ *      silently clobber each other server-side. We cannot fix a foreign writer
+ *      (operator console, another gateway), but we CAN guarantee that this
+ *      gateway never races itself: all write-backs for the same groupNo are
+ *      serialized through a per-groupNo promise-chain lock, so the read-modify-
+ *      write (PUT + cache update) for one call completes before the next starts.
+ *      Cross-source last-write-wins remains possible by design — see the caveat
+ *      on {@link GroupMdWriteback}.
+ *
+ * Owner-gating lives in the MCP tool layer (group-md-tool.ts), not here: this
+ * module is the mechanism, the tool is the policy boundary.
+ *
+ * Never persists anything to disk — the cache it updates is the same in-memory-
+ * only cache A's resolver reads (group-md-cache.ts), so this introduces no new
+ * durable-trust surface.
+ */
+import { updateGroupMd, updateThreadMd } from './octo/api.js';
+import type { GroupMdCache, ThreadMdCache } from './group-md-cache.js';
+/**
+ * Hard UTF-8 byte ceiling for GROUP.md content, per the XIN-201 measured
+ * server contract. A body above this is rejected locally (a server PUT would
+ * answer 400 err.server.bot_api.content_too_large).
+ */
+export declare const MAX_GROUP_MD_CONTENT_BYTES = 10240;
+/**
+ * Hard UTF-8 byte ceiling for THREAD.md content. The thread md endpoint shares
+ * the group md limit (P3-2 contract check: the official Octo web client edits
+ * both group and thread md through the SAME editor, whose `MAX_BYTES` is 10240),
+ * so this is an alias of {@link MAX_GROUP_MD_CONTENT_BYTES} rather than a second
+ * magic number — if the server limit ever diverges, the two can split here.
+ */
+export declare const MAX_THREAD_MD_CONTENT_BYTES = 10240;
+/** Thrown when content exceeds {@link MAX_GROUP_MD_CONTENT_BYTES}. */
+export declare class GroupMdContentTooLargeError extends Error {
+    readonly bytes: number;
+    constructor(bytes: number);
+}
+/** The `updateGroupMd` client signature, injectable for testing. */
+export type UpdateGroupMdFn = typeof updateGroupMd;
+/** Outcome of a successful write-back. */
+export interface GroupMdWriteResult {
+    groupNo: string;
+    /** Server-assigned version after the PUT. */
+    version: number;
+    /** UTF-8 byte length of the content that was written. */
+    bytes: number;
+}
+export interface GroupMdWriteParams {
+    apiUrl: string;
+    botToken: string;
+    groupNo: string;
+    content: string;
+    signal?: AbortSignal;
+}
+/**
+ * Serializes GROUP.md write-backs per groupNo and keeps A's cache in sync.
+ *
+ * Constructed ONCE per bot (alongside the GroupMdCache it updates) and shared
+ * across turns, so the per-groupNo lock actually spans concurrent agent turns —
+ * a per-turn instance would defeat the lock. The MCP tool server (built per
+ * turn) borrows this shared instance.
+ *
+ * CAVEAT (documented per XIN-201 item 4): the lock only covers THIS gateway. A
+ * write from another source (operator console, a second gateway process) is not
+ * coordinated and, because the server has no CAS, last-write-wins across sources
+ * — that is an accepted limitation, not a bug.
+ */
+export declare class GroupMdWriteback {
+    private readonly cache;
+    /** Injectable PUT client (defaults to the real octo client). */
+    private readonly updateFn;
+    /** Tail of the in-flight write chain per groupNo (serializes same-key writes). */
+    private readonly tails;
+    constructor(cache: GroupMdCache, 
+    /** Injectable PUT client (defaults to the real octo client). */
+    updateFn?: UpdateGroupMdFn);
+    /**
+     * Run `fn` after every previously-queued op for `key` has settled, so bodies
+     * for the same key never overlap. Different keys run independently. `fn`'s
+     * rejection is surfaced to its own caller; the chain tail swallows it so a
+     * failed write does not wedge later writes.
+     */
+    private withLock;
+    /**
+     * Persist `content` as the group's GROUP.md and refresh the cache.
+     *
+     * Rejects with {@link GroupMdContentTooLargeError} (before any server call)
+     * when content exceeds the UTF-8 byte limit; propagates the client error when
+     * the PUT itself fails (cache is left untouched in that case).
+     */
+    writeBack(params: GroupMdWriteParams): Promise<GroupMdWriteResult>;
+}
+/** The `updateThreadMd` client signature, injectable for testing. */
+export type UpdateThreadMdFn = typeof updateThreadMd;
+/** Thrown when THREAD.md content exceeds {@link MAX_THREAD_MD_CONTENT_BYTES}. */
+export declare class ThreadMdContentTooLargeError extends Error {
+    readonly bytes: number;
+    constructor(bytes: number);
+}
+/** Outcome of a successful THREAD.md write-back. */
+export interface ThreadMdWriteResult {
+    groupNo: string;
+    shortId: string;
+    /** Server-assigned version after the PUT. */
+    version: number;
+    /** UTF-8 byte length of the content that was written. */
+    bytes: number;
+}
+export interface ThreadMdWriteParams {
+    apiUrl: string;
+    botToken: string;
+    groupNo: string;
+    shortId: string;
+    content: string;
+    signal?: AbortSignal;
+}
+/**
+ * Thread analogue of {@link GroupMdWriteback} (P3-2): persists an agent-authored
+ * THREAD.md back to the server (PUT /v1/bot/groups/{groupNo}/threads/{shortId}/md
+ * via `updateThreadMd`), then refreshes the in-memory {@link ThreadMdCache} so
+ * the next resolve does not TTL-refetch a stale copy.
+ *
+ * Carries over every P2-C safety property, adapted to the thread key:
+ *
+ *   1. Same HARD ≤10240-byte (UTF-8) limit ({@link MAX_THREAD_MD_CONTENT_BYTES},
+ *      confirmed to equal the group limit — see that constant). Rejected locally
+ *      BEFORE the PUT so an oversized body never reaches the server.
+ *
+ *   2. The thread PUT, like the group PUT, does NOT compare-and-swap (body is
+ *      just `{ content }`, reply is `{ version }`). All write-backs for the same
+ *      thread are serialized through a per-`groupNo::shortId` promise-chain lock
+ *      so this gateway never races itself. Cross-source last-write-wins remains
+ *      possible by design, identical to the group caveat.
+ *
+ * Keyed by the COMPOSITE `groupNo::shortId` — the SAME key the thread cache and
+ * the P3-1 read side use — so a thread's write lock and cache refresh can never
+ * be confused with its parent group's (which the group coordinator locks by the
+ * bare groupNo). `::` is outside the safe-id charset, so the two key spaces are
+ * disjoint. Owner-gating lives in the MCP tool layer (group-md-tool.ts), not
+ * here. Never persists to disk — the cache it updates is the same memory-only
+ * cache the resolver reads.
+ */
+export declare class ThreadMdWriteback {
+    private readonly cache;
+    /** Injectable PUT client (defaults to the real octo client). */
+    private readonly updateFn;
+    /** Tail of the in-flight write chain per composite key (serializes same-thread writes). */
+    private readonly tails;
+    constructor(cache: ThreadMdCache, 
+    /** Injectable PUT client (defaults to the real octo client). */
+    updateFn?: UpdateThreadMdFn);
+    /** Composite lock key; mirrors ThreadMdCache's `groupNo::shortId`. */
+    private lockKey;
+    /**
+     * Run `fn` after every previously-queued op for `key` has settled, so bodies
+     * for the same key never overlap. Different keys run independently. `fn`'s
+     * rejection is surfaced to its own caller; the chain tail swallows it so a
+     * failed write does not wedge later writes. Identical policy to
+     * {@link GroupMdWriteback}.
+     */
+    private withLock;
+    /**
+     * Persist `content` as the thread's THREAD.md and refresh the thread cache.
+     *
+     * Rejects with {@link ThreadMdContentTooLargeError} (before any server call)
+     * when content exceeds the UTF-8 byte limit; propagates the client error when
+     * the PUT itself fails (cache is left untouched in that case).
+     */
+    writeBack(params: ThreadMdWriteParams): Promise<ThreadMdWriteResult>;
+}

package/dist/group-md-writeback.js

@@ -0,0 +1,223 @@
+/**
+ * GROUP.md write-back (P2-C): the app-layer coordinator that persists an
+ * agent-authored GROUP.md back to the server (PUT /v1/bot/groups/{groupNo}/md)
+ * via A's `updateGroupMd` client, then refreshes A's in-memory cache so the next
+ * resolve does not TTL-refetch a stale copy.
+ *
+ * Two server-contract facts (XIN-201, measured — NOT inferred) shape this:
+ *
+ *   1. content has a HARD ≤10240-byte (UTF-8) limit; the server answers an
+ *      oversized body with 400 err.server.bot_api.content_too_large. We reject
+ *      locally BEFORE the PUT so a too-large write never reaches the server.
+ *
+ *   2. `version` is a server-side monotonic counter and the PUT does NOT do
+ *      compare-and-swap (last-write-wins, no CAS). Concurrent writers therefore
+ *      silently clobber each other server-side. We cannot fix a foreign writer
+ *      (operator console, another gateway), but we CAN guarantee that this
+ *      gateway never races itself: all write-backs for the same groupNo are
+ *      serialized through a per-groupNo promise-chain lock, so the read-modify-
+ *      write (PUT + cache update) for one call completes before the next starts.
+ *      Cross-source last-write-wins remains possible by design — see the caveat
+ *      on {@link GroupMdWriteback}.
+ *
+ * Owner-gating lives in the MCP tool layer (group-md-tool.ts), not here: this
+ * module is the mechanism, the tool is the policy boundary.
+ *
+ * Never persists anything to disk — the cache it updates is the same in-memory-
+ * only cache A's resolver reads (group-md-cache.ts), so this introduces no new
+ * durable-trust surface.
+ */
+import { updateGroupMd, updateThreadMd } from './octo/api.js';
+/**
+ * Hard UTF-8 byte ceiling for GROUP.md content, per the XIN-201 measured
+ * server contract. A body above this is rejected locally (a server PUT would
+ * answer 400 err.server.bot_api.content_too_large).
+ */
+export const MAX_GROUP_MD_CONTENT_BYTES = 10240;
+/**
+ * Hard UTF-8 byte ceiling for THREAD.md content. The thread md endpoint shares
+ * the group md limit (P3-2 contract check: the official Octo web client edits
+ * both group and thread md through the SAME editor, whose `MAX_BYTES` is 10240),
+ * so this is an alias of {@link MAX_GROUP_MD_CONTENT_BYTES} rather than a second
+ * magic number — if the server limit ever diverges, the two can split here.
+ */
+export const MAX_THREAD_MD_CONTENT_BYTES = MAX_GROUP_MD_CONTENT_BYTES;
+/** Thrown when content exceeds {@link MAX_GROUP_MD_CONTENT_BYTES}. */
+export class GroupMdContentTooLargeError extends Error {
+    bytes;
+    constructor(bytes) {
+        super(`GROUP.md content is ${bytes} bytes, over the ${MAX_GROUP_MD_CONTENT_BYTES}-byte UTF-8 limit`);
+        this.bytes = bytes;
+        this.name = 'GroupMdContentTooLargeError';
+    }
+}
+/**
+ * Serializes GROUP.md write-backs per groupNo and keeps A's cache in sync.
+ *
+ * Constructed ONCE per bot (alongside the GroupMdCache it updates) and shared
+ * across turns, so the per-groupNo lock actually spans concurrent agent turns —
+ * a per-turn instance would defeat the lock. The MCP tool server (built per
+ * turn) borrows this shared instance.
+ *
+ * CAVEAT (documented per XIN-201 item 4): the lock only covers THIS gateway. A
+ * write from another source (operator console, a second gateway process) is not
+ * coordinated and, because the server has no CAS, last-write-wins across sources
+ * — that is an accepted limitation, not a bug.
+ */
+export class GroupMdWriteback {
+    cache;
+    updateFn;
+    /** Tail of the in-flight write chain per groupNo (serializes same-key writes). */
+    tails = new Map();
+    constructor(cache, 
+    /** Injectable PUT client (defaults to the real octo client). */
+    updateFn = updateGroupMd) {
+        this.cache = cache;
+        this.updateFn = updateFn;
+    }
+    /**
+     * Run `fn` after every previously-queued op for `key` has settled, so bodies
+     * for the same key never overlap. Different keys run independently. `fn`'s
+     * rejection is surfaced to its own caller; the chain tail swallows it so a
+     * failed write does not wedge later writes.
+     */
+    withLock(key, fn) {
+        const prev = this.tails.get(key) ?? Promise.resolve();
+        const result = prev.then(fn, fn); // run regardless of prior success/failure
+        const tail = result.then(() => undefined, () => undefined);
+        this.tails.set(key, tail);
+        // Best-effort cleanup: drop the key once the queue drains to this tail, so
+        // the Map does not grow without bound across many groups.
+        tail.then(() => {
+            if (this.tails.get(key) === tail)
+                this.tails.delete(key);
+        });
+        return result;
+    }
+    /**
+     * Persist `content` as the group's GROUP.md and refresh the cache.
+     *
+     * Rejects with {@link GroupMdContentTooLargeError} (before any server call)
+     * when content exceeds the UTF-8 byte limit; propagates the client error when
+     * the PUT itself fails (cache is left untouched in that case).
+     */
+    async writeBack(params) {
+        const { apiUrl, botToken, groupNo, content, signal } = params;
+        const bytes = Buffer.byteLength(content, 'utf-8');
+        if (bytes > MAX_GROUP_MD_CONTENT_BYTES) {
+            // Reject locally — do NOT hit the server (it would answer 400).
+            throw new GroupMdContentTooLargeError(bytes);
+        }
+        return this.withLock(groupNo, async () => {
+            const { version } = await this.updateFn({ apiUrl, botToken, groupNo, content, signal });
+            // Write the just-persisted content/version back into A's in-memory cache
+            // so the next resolveGroupInstructions serves what we wrote instead of
+            // either re-fetching (TTL) or, worse, returning a now-stale cached copy.
+            // updated_at is null because the PUT response carries only { version }.
+            this.cache.set(groupNo, {
+                content,
+                version: typeof version === 'number' ? version : 0,
+                updated_at: null,
+            });
+            return { groupNo, version, bytes };
+        });
+    }
+}
+/** Thrown when THREAD.md content exceeds {@link MAX_THREAD_MD_CONTENT_BYTES}. */
+export class ThreadMdContentTooLargeError extends Error {
+    bytes;
+    constructor(bytes) {
+        super(`THREAD.md content is ${bytes} bytes, over the ${MAX_THREAD_MD_CONTENT_BYTES}-byte UTF-8 limit`);
+        this.bytes = bytes;
+        this.name = 'ThreadMdContentTooLargeError';
+    }
+}
+/**
+ * Thread analogue of {@link GroupMdWriteback} (P3-2): persists an agent-authored
+ * THREAD.md back to the server (PUT /v1/bot/groups/{groupNo}/threads/{shortId}/md
+ * via `updateThreadMd`), then refreshes the in-memory {@link ThreadMdCache} so
+ * the next resolve does not TTL-refetch a stale copy.
+ *
+ * Carries over every P2-C safety property, adapted to the thread key:
+ *
+ *   1. Same HARD ≤10240-byte (UTF-8) limit ({@link MAX_THREAD_MD_CONTENT_BYTES},
+ *      confirmed to equal the group limit — see that constant). Rejected locally
+ *      BEFORE the PUT so an oversized body never reaches the server.
+ *
+ *   2. The thread PUT, like the group PUT, does NOT compare-and-swap (body is
+ *      just `{ content }`, reply is `{ version }`). All write-backs for the same
+ *      thread are serialized through a per-`groupNo::shortId` promise-chain lock
+ *      so this gateway never races itself. Cross-source last-write-wins remains
+ *      possible by design, identical to the group caveat.
+ *
+ * Keyed by the COMPOSITE `groupNo::shortId` — the SAME key the thread cache and
+ * the P3-1 read side use — so a thread's write lock and cache refresh can never
+ * be confused with its parent group's (which the group coordinator locks by the
+ * bare groupNo). `::` is outside the safe-id charset, so the two key spaces are
+ * disjoint. Owner-gating lives in the MCP tool layer (group-md-tool.ts), not
+ * here. Never persists to disk — the cache it updates is the same memory-only
+ * cache the resolver reads.
+ */
+export class ThreadMdWriteback {
+    cache;
+    updateFn;
+    /** Tail of the in-flight write chain per composite key (serializes same-thread writes). */
+    tails = new Map();
+    constructor(cache, 
+    /** Injectable PUT client (defaults to the real octo client). */
+    updateFn = updateThreadMd) {
+        this.cache = cache;
+        this.updateFn = updateFn;
+    }
+    /** Composite lock key; mirrors ThreadMdCache's `groupNo::shortId`. */
+    lockKey(groupNo, shortId) {
+        return `${groupNo}::${shortId}`;
+    }
+    /**
+     * Run `fn` after every previously-queued op for `key` has settled, so bodies
+     * for the same key never overlap. Different keys run independently. `fn`'s
+     * rejection is surfaced to its own caller; the chain tail swallows it so a
+     * failed write does not wedge later writes. Identical policy to
+     * {@link GroupMdWriteback}.
+     */
+    withLock(key, fn) {
+        const prev = this.tails.get(key) ?? Promise.resolve();
+        const result = prev.then(fn, fn); // run regardless of prior success/failure
+        const tail = result.then(() => undefined, () => undefined);
+        this.tails.set(key, tail);
+        tail.then(() => {
+            if (this.tails.get(key) === tail)
+                this.tails.delete(key);
+        });
+        return result;
+    }
+    /**
+     * Persist `content` as the thread's THREAD.md and refresh the thread cache.
+     *
+     * Rejects with {@link ThreadMdContentTooLargeError} (before any server call)
+     * when content exceeds the UTF-8 byte limit; propagates the client error when
+     * the PUT itself fails (cache is left untouched in that case).
+     */
+    async writeBack(params) {
+        const { apiUrl, botToken, groupNo, shortId, content, signal } = params;
+        const bytes = Buffer.byteLength(content, 'utf-8');
+        if (bytes > MAX_THREAD_MD_CONTENT_BYTES) {
+            // Reject locally — do NOT hit the server (it would answer 400).
+            throw new ThreadMdContentTooLargeError(bytes);
+        }
+        return this.withLock(this.lockKey(groupNo, shortId), async () => {
+            const { version } = await this.updateFn({ apiUrl, botToken, groupNo, shortId, content, signal });
+            // Refresh the just-persisted content/version into the in-memory thread
+            // cache (composite-keyed) so the next resolveGroupInstructions thread
+            // branch serves what we wrote instead of re-fetching or serving a stale
+            // copy. updated_at is null because the PUT response carries only { version }.
+            this.cache.set(groupNo, shortId, {
+                content,
+                version: typeof version === 'number' ? version : 0,
+                updated_at: null,
+            });
+            return { groupNo, shortId, version, bytes };
+        });
+    }
+}
+//# sourceMappingURL=group-md-writeback.js.map

package/dist/group-md-writeback.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"group-md-writeback.js","sourceRoot":"","sources":["../src/group-md-writeback.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AAEH,OAAO,EAAE,aAAa,EAAE,cAAc,EAAE,MAAM,eAAe,CAAC;AAG9D;;;;GAIG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG,KAAK,CAAC;AAEhD;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,2BAA2B,GAAG,0BAA0B,CAAC;AAEtE,sEAAsE;AACtE,MAAM,OAAO,2BAA4B,SAAQ,KAAK;IACxB;IAA5B,YAA4B,KAAa;QACvC,KAAK,CACH,uBAAuB,KAAK,oBAAoB,0BAA0B,mBAAmB,CAC9F,CAAC;QAHwB,UAAK,GAAL,KAAK,CAAQ;QAIvC,IAAI,CAAC,IAAI,GAAG,6BAA6B,CAAC;IAC5C,CAAC;CACF;AAsBD;;;;;;;;;;;;GAYG;AACH,MAAM,OAAO,gBAAgB;IAKR;IAEA;IANnB,kFAAkF;IACjE,KAAK,GAAG,IAAI,GAAG,EAA4B,CAAC;IAE7D,YACmB,KAAmB;IACpC,gEAAgE;IAC/C,WAA4B,aAAa;QAFzC,UAAK,GAAL,KAAK,CAAc;QAEnB,aAAQ,GAAR,QAAQ,CAAiC;IACzD,CAAC;IAEJ;;;;;OAKG;IACK,QAAQ,CAAI,GAAW,EAAE,EAAoB;QACnD,MAAM,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,IAAI,OAAO,CAAC,OAAO,EAAE,CAAC;QACtD,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC,0CAA0C;QAC5E,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,CACtB,GAAG,EAAE,CAAC,SAAS,EACf,GAAG,EAAE,CAAC,SAAS,CAChB,CAAC;QACF,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,IAAI,CAAC,CAAC;QAC1B,2EAA2E;QAC3E,0DAA0D;QAC1D,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE;YACb,IAAI,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,IAAI;gBAAE,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;QAC3D,CAAC,CAAC,CAAC;QACH,OAAO,MAAM,CAAC;IAChB,CAAC;IAED;;;;;;OAMG;IACH,KAAK,CAAC,SAAS,CAAC,MAA0B;QACxC,MAAM,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,EAAE,GAAG,MAAM,CAAC;QAC9D,MAAM,KAAK,GAAG,MAAM,CAAC,UAAU,CAAC,OAAO,EAAE,OAAO,CAAC,CAAC;QAClD,IAAI,KAAK,GAAG,0BAA0B,EAAE,CAAC;YACvC,gEAAgE;YAChE,MAAM,IAAI,2BAA2B,CAAC,KAAK,CAAC,CAAC;QAC/C,CAAC;QACD,OAAO,IAAI,CAAC,QAAQ,CAAC,OAAO,EAAE,KAAK,IAAI,EAAE;YACvC,MAAM,EAAE,OAAO,EAAE,GAAG,MAAM,IAAI,CAAC,QAAQ,CAAC,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,EAAE,CAAC,CAAC;YACxF,yEAAyE;YACzE,uEAAuE;YACvE,yEAAyE;YACzE,wEAAwE;YACxE,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,OAAO,EAAE;gBACtB,OAAO;gBACP,OAAO,EAAE,OAAO,OAAO,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;gBAClD,UAAU,EAAE,IAAI;aACjB,CAAC,CAAC;YACH,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;QACrC,CAAC,CAAC,CAAC;IACL,CAAC;CACF;AAKD,iFAAiF;AACjF,MAAM,OAAO,4BAA6B,SAAQ,KAAK;IACzB;IAA5B,YAA4B,KAAa;QACvC,KAAK,CACH,wBAAwB,KAAK,oBAAoB,2BAA2B,mBAAmB,CAChG,CAAC;QAHwB,UAAK,GAAL,KAAK,CAAQ;QAIvC,IAAI,CAAC,IAAI,GAAG,8BAA8B,CAAC;IAC7C,CAAC;CACF;AAqBD;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,MAAM,OAAO,iBAAiB;IAKT;IAEA;IANnB,2FAA2F;IAC1E,KAAK,GAAG,IAAI,GAAG,EAA4B,CAAC;IAE7D,YACmB,KAAoB;IACrC,gEAAgE;IAC/C,WAA6B,cAAc;QAF3C,UAAK,GAAL,KAAK,CAAe;QAEpB,aAAQ,GAAR,QAAQ,CAAmC;IAC3D,CAAC;IAEJ,sEAAsE;IAC9D,OAAO,CAAC,OAAe,EAAE,OAAe;QAC9C,OAAO,GAAG,OAAO,KAAK,OAAO,EAAE,CAAC;IAClC,CAAC;IAED;;;;;;OAMG;IACK,QAAQ,CAAI,GAAW,EAAE,EAAoB;QACnD,MAAM,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,IAAI,OAAO,CAAC,OAAO,EAAE,CAAC;QACtD,MAAM,MAAM,GAAG,IAAI,CAAC,IAAI,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC,0CAA0C;QAC5E,MAAM,IAAI,GAAG,MAAM,CAAC,IAAI,CACtB,GAAG,EAAE,CAAC,SAAS,EACf,GAAG,EAAE,CAAC,SAAS,CAChB,CAAC;QACF,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,EAAE,IAAI,CAAC,CAAC;QAC1B,IAAI,CAAC,IAAI,CAAC,GAAG,EAAE;YACb,IAAI,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,IAAI;gBAAE,IAAI,CAAC,KAAK,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;QAC3D,CAAC,CAAC,CAAC;QACH,OAAO,MAAM,CAAC;IAChB,CAAC;IAED;;;;;;OAMG;IACH,KAAK,CAAC,SAAS,CAAC,MAA2B;QACzC,MAAM,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,EAAE,GAAG,MAAM,CAAC;QACvE,MAAM,KAAK,GAAG,MAAM,CAAC,UAAU,CAAC,OAAO,EAAE,OAAO,CAAC,CAAC;QAClD,IAAI,KAAK,GAAG,2BAA2B,EAAE,CAAC;YACxC,gEAAgE;YAChE,MAAM,IAAI,4BAA4B,CAAC,KAAK,CAAC,CAAC;QAChD,CAAC;QACD,OAAO,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,OAAO,CAAC,EAAE,KAAK,IAAI,EAAE;YAC9D,MAAM,EAAE,OAAO,EAAE,GAAG,MAAM,IAAI,CAAC,QAAQ,CAAC,EAAE,MAAM,EAAE,QAAQ,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,EAAE,CAAC,CAAC;YACjG,uEAAuE;YACvE,sEAAsE;YACtE,wEAAwE;YACxE,8EAA8E;YAC9E,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,OAAO,EAAE,OAAO,EAAE;gBAC/B,OAAO;gBACP,OAAO,EAAE,OAAO,OAAO,KAAK,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;gBAClD,UAAU,EAAE,IAAI;aACjB,CAAC,CAAC;YACH,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;QAC9C,CAAC,CAAC,CAAC;IACL,CAAC;CACF"}

package/dist/group-md.d.ts

@@ -1,53 +1,76 @@
 /**
- * GROUP.md resolution (P2-A): server-first fetch with a never-lose local-file
- * fallback, behind a feature flag.
+ * GROUP.md / THREAD.md resolution: server-first fetch with a never-lose
+ * local-file fallback, behind a feature flag.
  *
  * `resolveGroupInstructions` is the single entry point the message pipeline
- * calls to obtain the trusted per-group instruction block injected into the
- * agent's system prompt. Resolution order:
+ * calls to obtain the trusted per-conversation instruction block injected into
+ * the agent's system prompt.
  *
+ * 🔴 Thread vs group are MUTUALLY EXCLUSIVE (老板拍板口径, #88 P3). The entry
+ * point routes on channelId shape:
+ *   - A thread (`<groupNo>____<shortId>`, CommunityTopic) resolves its OWN
+ *     THREAD.md only. It NEVER falls back to — nor stacks — the parent group's
+ *     GROUP.md, and it NEVER reads or writes the group's `groupMdCache` (which
+ *     is keyed by the parent groupNo). See `resolveThreadInstructions`.
+ *   - A plain group (`<groupNo>`, no separator) resolves its GROUP.md exactly as
+ *     before — the group branch below is byte-for-byte the pre-P3 behavior.
+ *
+ * The bug this fixes (XIN-224): the old resolver collapsed EVERY channelId to
+ * its parent groupNo via `extractParentGroupNo`, so with `serverMd` on a thread
+ * message was injected the parent group's GROUP.md — violating the redline that
+ * a thread injects only its own THREAD.md.
+ *
+ * Group-branch resolution order (unchanged):
  *   1. Feature flag OFF (default) or no cache wired → pure local file
- *      (`loadGroupConfig`). Byte-identical to the pre-P2 behavior, so existing
- *      local-file deployments are unaffected.
+ *      (`loadGroupConfig`). Byte-identical to the pre-P2 behavior.
  *   2. Feature flag ON:
  *        a. serve a cached server GROUP.md if present and not past its TTL (keyed
- *           by the PARENT group number — a thread shares its parent group's
- *           GROUP.md). The cache is IN-MEMORY ONLY (no disk), so the only way
- *           content reaches this trusted system-prompt channel is a live,
- *           authenticated fetch — never a forgeable on-disk artifact a chat-
- *           driven Bash/Write could plant (review #172 🔴; see group-md-cache.ts);
+ *           by the group number). The cache is IN-MEMORY ONLY (no disk), so the
+ *           only way content reaches this trusted system-prompt channel is a
+ *           live, authenticated fetch — never a forgeable on-disk artifact
+ *           (review #172 🔴; see group-md-cache.ts);
  *        b. otherwise fetch from the server (server-first). On success with
  *           non-empty content, cache it and use it;
  *        c. on ANY failure (404 "no GROUP.md", network, timeout, empty content)
  *           fall back to the local file. The local-file path is never lost.
  *
- * Trust: server content stands on its own trust root — an authenticated
- * `getGroupMd` over the bot token against the SSRF-validated `apiUrl`, server-
- * side bot_admin-gated — NOT on the OS-permission trust the local `groupConfigDir`
- * file relies on. By caching only in memory we never let server content
- * masquerade as (or be confused with) a trusted local file on disk.
+ * Thread-branch resolution order (P3-1) mirrors the group branch, keyed by the
+ * COMPOSITE `<groupNo>::<shortId>` (see `resolveThreadInstructions`), gated on
+ * the independent `threadMd` flag; when the flag is off a thread still resolves
+ * its local `<shortId>.md` (already the correct non-stacking behavior).
  *
- * Thread routing (P1): a thread channelId is the composite `<groupNo>____<shortId>`.
- * The server GROUP.md endpoint is keyed by the parent group number, so we resolve
- * it with `extractParentGroupNo` for the API call + cache key (identity for a
- * plain group). The local-file fallback still receives the FULL channelId so its
- * own thread/short-id routing in `loadGroupConfig` is preserved unchanged.
+ * Trust: server content stands on its own trust root — an authenticated
+ * `getGroupMd` / `getThreadMd` over the bot token against the SSRF-validated
+ * `apiUrl` — NOT on the OS-permission trust the local `groupConfigDir` file
+ * relies on. By caching only in memory we never let server content masquerade
+ * as (or be confused with) a trusted local file on disk.
  *
  * Never throws — a server error degrades to local, a local miss degrades to
  * "no custom instructions".
  */
-import type { GroupMdCache } from './group-md-cache.js';
+import type { GroupMdCache, ThreadMdCache } from './group-md-cache.js';
 export interface ResolveGroupInstructionsParams {
     /** Operator local-instruction directory (the existing fallback source). */
     groupConfigDir?: string;
-    /** Feature flag: when false/undefined, server fetch is skipped entirely. */
+    /** Feature flag: when false/undefined, server GROUP.md fetch is skipped. */
     serverMd?: boolean;
+    /**
+     * P3-1 feature flag: when true, a THREAD channel resolves its THREAD.md
+     * server-first (GET /v1/bot/groups/{groupNo}/threads/{shortId}/md) before its
+     * local `<shortId>.md`. When false/undefined (default) a thread resolves ONLY
+     * its local file — which is already the correct non-stacking behavior, so the
+     * flag gates the NEW server-read capability, not the bug fix. Independent of
+     * `serverMd` (which governs the group server-read path).
+     */
+    threadMd?: boolean;
     apiUrl: string;
     botToken: string;
     /** Full channelId (may be a `<groupNo>____<shortId>` thread composite). */
     channelId: string;
-    /** Server GROUP.md cache. Omitted (or flag off) → pure local file. */
+    /** Server GROUP.md cache (group branch). Omitted (or flag off) → pure local. */
     cache?: GroupMdCache;
+    /** Server THREAD.md cache (thread branch). Omitted (or flag off) → pure local. */
+    threadCache?: ThreadMdCache;
     signal?: AbortSignal;
 }
 export declare function resolveGroupInstructions(params: ResolveGroupInstructionsParams): Promise<string | undefined>;