talking-stick 0.1.3 → 0.1.4

package/dist/cli/room-commands.js

@@ -31,7 +31,11 @@ export function handleJoinCommand(runtime, parsed) {
     });
     upsertSessionFromJoin(identity, joined);
     printResult(parsed, joined, () => {
-        return `Joined ${joined.canonical_path} as ${joined.agent_id}`;
+        const lines = [`Joined ${joined.canonical_path} as ${joined.agent_id}`];
+        if (joined.warning) {
+            lines.push(`Warning: ${joined.warning}`);
+        }
+        return lines.join("\n");
     });
 }
 export function handleLeaveCommand(runtime, parsed) {

package/dist/service.js

@@ -682,7 +682,11 @@ export class TalkingStickService {
         if (forceNew) {
             const exactRoom = this.findRoomByCanonicalPath(resolved.canonical_context_path);
             if (exactRoom) {
-                return { room: exactRoom, joinedExistingRoom: true };
+                return {
+                    room: exactRoom,
+                    joinedExistingRoom: true,
+                    warning: `force_new had no effect: a room already exists at ${exactRoom.canonical_path}. force_new only creates a nested room when an ancestor room exists; same-path duplicates are not supported. To get a fresh room for a separate topic, join a distinct subpath.`
+                };
             }
             return {
                 room: this.createRoom(resolved.canonical_context_path, timestamp),

package/docs/releases/0.1.4.md

@@ -0,0 +1,68 @@
+# Talking Stick 0.1.4
+
+Date: 2026-04-30
+
+Patch release that clarifies the existing `force_new` semantics on `join_path`,
+makes the resulting warnings visible to human CLI users, and stabilizes the
+test suite.
+
+## Fixed
+
+### `force_new` no-op on exact-path joins now surfaces a warning
+
+`join_path` has always had two shapes for `force_new=true`: it creates a nested
+room when a different ancestor room exists, and it joins the existing room
+when one already exists at the exact `canonical_path` (because
+`path_rooms.canonical_path` is `UNIQUE`). The second shape is a deliberate
+no-op — `force_new` cannot duplicate a room at the same canonical path — but
+prior versions returned the existing room silently with `joined_existing_room:
+true` and no further signal. Operators and harnesses who flipped `--force-new`
+expecting a fresh room had no way to tell their request had no effect.
+
+`join_path` now returns a `warning` field on this no-op path explaining what
+happened and pointing the caller at the only remedy: join a distinct subpath
+(for example a topic-scoped subdirectory) to get a fresh room. The nested-room
+warning that has always existed is unchanged. Both warnings are now also
+rendered in the default `tt join` text output, not just `--json`.
+
+In practice this means a Claude Code or Codex harness asking for a new "topic
+room" at the same path now sees an explicit signal that the API only knows
+about path-scoped rooms, instead of silently working off the existing room.
+
+The bundled skill's *While waiting* section also gains a more proactive
+framing: the wait window is the right place to re-read the holder's last
+handoff, follow its `artifacts[]`, investigate, and surface findings via
+`add_note` — not idle sleep.
+
+### Contention test no longer races the room-purge clock
+
+`tests/talking-stick.test.ts > only one process can claim an idle room under
+contention` reproduced as a `room_not_found` failure when the wall-clock date
+crossed the `idleRoomTtlMs` window relative to the parent test's fake clock
+fixed at 2026-04-22. The contention worker spawned in
+`tests/fixtures/claim-worker.ts` constructed its `TalkingStickService` with
+the real `Date.now()`, so the worker's `purgeExpiredIdleRooms` call evicted
+the room that the parent had just created under the fake clock. The fix
+threads the parent's fake-clock ISO timestamp into the worker so the service
+shares the same `now()` source, and the test passes deterministically
+regardless of wall-clock date.
+
+### Identity-resolver memoization test no longer asserts internal call counts
+
+`tests/mcp-server.test.ts > createConnectionIdentityResolver > memoizes
+derived identity per session and re-derives on override` was written when
+`deriveMcpHarnessIdentity` made one `inspector.inspect` call per derive.
+Since 0.1.3's ancestry-walk fix (commit `ab4e843`), a single derive may walk
+multiple parent processes. The resolver-level memoization is still correct;
+the test was asserting the wrong invariant. Updated to assert call-count
+*deltas* across resolver invocations (no growth on memoized hits, growth on
+fresh sessions and overrides) instead of absolute counts, so the test
+remains robust to changes in ancestry-walk depth.
+
+## Verification
+
+- `npm run typecheck`
+- `npm test` — 225 tests across 14 files, all passing under Node 24.11.0
+- `npm run build`
+- `git diff --check`
+- `npm pack --dry-run --ignore-scripts`

package/docs/talking-stick-plan.md

@@ -316,7 +316,7 @@ Resolution:
 2. Resolve the preferred workspace root.
 3. Walk up from the canonical `context_path` to the preferred workspace root looking for an existing room.
 4. If found and `force_new = false`: join the deepest existing ancestor room.
-5. If found and `force_new = true`: create a nested room at the canonical `context_path`, returning a warning that an ancestor room exists. If a room already exists at that exact path, join it.
+5. If found and `force_new = true`: create a nested room at the canonical `context_path`, returning a warning that an ancestor room exists. If a room already exists at the exact `canonical_context_path`, join it and return a warning that `force_new` was a no-op. `force_new` only creates *nested* rooms; it never duplicates a room at the same canonical path because `path_rooms.canonical_path` is unique. Callers that want a fresh room for a separate topic must join a distinct subpath.
 6. If not found: create a new room at the preferred workspace root.
 
 The response includes the resolved `room_id`, the `canonical_path` the agent actually joined (which may differ from the request path when workspace root resolution or ancestor lookup redirected the call), the effective room policy (including `heartbeat_interval_ms`), and a `handoff_template` hint describing the expected handoff shape. For the MVP this template is static server-wide; room-specific prompting can be added later if real workflows need it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "talking-stick",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "MCP coordination server for path-scoped agent handoffs.",
   "type": "module",
   "bin": {

package/skills/talking-stick/SKILL.md

@@ -91,7 +91,7 @@ If you do not have the stick:
 - it is fine to read, plan, review, or help the user think — or any other work that does not mutate shared state
 - tell the user who currently holds or is reserved the turn when that is useful
 
-If you notice something the current owner should know — a subtle invariant near code they are about to touch, a related bug you spotted while reading, a pointer to a doc — leave a note with `add_note` instead of sitting on it until your next turn. Notes do not grant permission to edit shared files; they are observations and pointers, not coordination bypasses.
+The wait is for *active* non-mutating work, not idle sleep. Re-read the holder's last handoff, follow up on its `artifacts[]`, investigate the area they are touching, and rethink the plan from your own angle. If you find something the holder should know — a missed invariant, a related bug, a sharper plan — leave a note with `add_note` rather than sitting on it until your next turn. Notes do not grant permission to edit shared files; they are observations and pointers, not coordination bypasses. The point: while you wait you can still move the work forward by feeding the holder, not by stalling.
 
 When you do take the stick, first read the attached handoff and load any useful `artifacts[]`, then run `list_notes` once so you see what other members left for you. The owner's turn is the right place to act on a note, not to debate it with its author mid-turn.