v1.27.0

Highlights: the tree now follows the doc you're working in — in the Roadmap view too, and across view toggles, sidebar switches, and window reload — and the package-layer architecture rule is now enforced end-to-end by one table-driven guard.

Changed

• The tree selection follows the open doc — in both views, on every trigger. Opening a doc now selects its node in the Roadmap view as well (falling back to the doc's thread node when the roadmap has no exact doc row), and the selection keeps up everywhere it used to lag: toggling Show Roadmap ⇄ Show Threads with a doc open, switching to another sidebar tool and back to Loom, re-enabling doc→tree sync (it jumps to the current doc immediately), and opening VS Code with a doc already open. Threads-view exact-node precision is unchanged.
• The layer rule is now machine-enforced across the whole package graph. A single table-driven guard checks every package edge (cli/vscode → mcp → app → core + fs + telemetry) on both axes — sibling-package imports and direct node fs access — and resolves relative imports, so cross-package edges can no longer slip past a specifier-only scan. It subsumes the two old per-package guards, keeps their documented exceptions, and fails red for any new package without a declared row.

v1.26.0

Highlights: wire thread dependencies visually from the roadmap, clicking a roadmap thread now drops you into its live chat, a new next-work report mines the graph for what to build next, and the three READMEs are lighter entry points.

Added

• Wire thread dependencies visually. Right-click a thread in the roadmap (or tree) → Set Dependencies… to set its depends_on edges from a multi-select list pre-checked with the current graph — no more hand-editing thread.md or dropping to the CLI. The pre-checked picker doubles as the "what does this depend on today" view, and a dependency that would form a cycle is refused with a clear message. Completes CLI ⇄ MCP ⇄ extension parity for dependency editing.
• A next-work report. A new prospective report kind mines the doc graph's still-open material to propose what to work on next, with forward and creativity knobs to steer how far ahead and how inventive the suggestions run.

Changed

• Clicking a roadmap thread resumes the conversation. A roadmap thread now opens its latest still-open chat first (falling back to design → idea → thread manifest), so you land where the work actually is instead of on the spec.
• Cross-plan blockers are no longer silently dropped. A step's blockedBy reference to another plan is now validated and warn-and-stored, with a standing diagnostic that surfaces any dangling plan reference — so a cross-plan dependency survives even when its target isn't loaded, instead of vanishing at write time.
• Lighter README entry points. The three READMEs (root, CLI, VS Code) are now deliberately light — one pain-first tagline, a quick-start, and a doc-map — with the exhaustive material kept in the linked docs, and that "light entry point" rule is now encoded in the doc-sync contract so it stays that way.

Fixed

• Set Dependencies now appears in the roadmap view. The Set Dependencies… menu item was only showing on tree-view thread nodes; it now also shows on roadmap thread nodes — the view where you can see the candidate threads in dependency order.

v1.25.0

Added

• Release notes drafted from your doc graph — loom report release-notes. Loom now writes your changelog for you: the command selects the Unreleased work (done plans not yet stamped with a release — exactly what's about to ship), enriches each one from its done-doc detail, and drafts a Highlights lead → Added / Changed / Fixed section under ## [Unreleased], in user-benefit language rather than raw commit subjects. It runs in your release CI — --run hands the brief to a headless agent that writes and saves the notes, --titles-only gives a fast low-token draft — and it's guarded: with nothing unreleased it returns a "NOTHING UNRELEASED" stop-signal (naming any threads still mid-implementation) instead of an empty changelog. The same command backs /do-release, so the tool drafts its own release notes from the decision graph instead of a hand-read of git log. (These notes were drafted by it.)
• ctx in the CLI and the VS Code tree. A new loom refresh-ctx command mirrors the MCP tool (tri-surface parity), with --skeleton to seed just the pillar headings + authoring hints (no AI). The extension gains a global Context node with a Refresh action and an honest "refreshed {date}" recency line — the first time loom/ctx.md is visible and refreshable from the human surface.
• A project-agnostic ctx template. A fresh loom/ctx.md seeds six pillars — Architecture · API & contracts · Stack · Build/Test/CI · Documentation map · AI collaboration — with authoring hints; refreshing an existing ctx preserves the sections you already wrote rather than overwriting them.

Changed

• ctx is now global-only. Loom keeps a single loom/ctx.md per project; per-weave and per-thread ctx docs are retired (the parent chain already loads each thread's idea / design / plan in full, so scoped ctx was redundant). One place to look, one doc to refresh. Clean removal — no deprecation shim.
• /do-release drafts its changelog from the graph, not git log. The release runbook now runs loom report release-notes for the draft and keeps git log only as a coverage net (flagging any user-facing commit with no covering done plan), with a built-in guard that stops a release when nothing is actually unreleased.

Fixed

• ctx refresh preserves a doc's original created date instead of resetting it to today, and the new last_refreshed stamp renders as a plain YYYY-MM-DD date in the tree (not a raw timestamp).

v1.24.0

Added

• Doc-graph reports — analytical reports from your project's reasoning, not just its code. A new loom report <kind> command (plus a report MCP prompt and a loom_create_report tool) synthesizes a report from a filtered slice of the Loom document graph — chats, ideas, designs, plans, done-notes, roadmap. Because it reads the reasoning layer, it can answer what a codebase-only tool structurally cannot: why a decision was taken, which alternatives lost, where implementation drifted from design. Kinds: project-overview, decisions, architecture, designs, ideas, plans, dones, drift-audit, security, release-notes. The server deterministically selects a token-budgeted slice — filter with --weave / --thread / --since / --until, tiered degradation with a selectable --sort recency|oldest, or --full to send the whole slice — and the agent synthesizes it in the real loop (never captive sampling). Reports persist as versioned report docs (rp_ ULID) under loom/reports/, cite every source doc, and surface in the VS Code tree under a dedicated Reports node with a Generate Report action. loom report <kind> --run launches a headless Claude agent to generate and save end-to-end. See the reports reference.
• load / read / reply slang split — pay for a thread's context once. Pointed context is now a heavy-once load (the full thread bundle, which sets the active thread) plus cheap doc-only read / reply, so a doc in an already-loaded thread costs just that doc instead of re-bundling the whole thread on every pointed read. Adds ?scope=doc on loom://context/... and loom context <path> --scope doc on the CLI (tri-surface parity). Reading a chat that has an unanswered turn now flows straight into reply.

Changed

• loom_quick_ship takes an optional title. Quick-shipped plans previously inherited a generic {thread} Plan title, giving roadmap history non-descriptive entries. A passed title now lands on the plan; omitting it keeps the existing fallback.

Fixed

• VS Code tree: empty Reports / Refs / Context nodes always render. Each of those nodes was hidden when it had no children — but the action that creates the first report / reference / ctx lives on that node, a chicken-and-egg empty state (hit on a fresh Chord Flow workspace). The nodes now always render with a click-to-generate placeholder; per-weave / per-thread subsections stay data-driven so the tree gains no clutter.

v1.23.0

Added

• A unified loom create <type> command. One thread-first namespace replaces the old loom weave idea|design|plan, mirroring loom_create_* across all eight doc types — loom create thread|idea|design|plan|req|chat|reference|weave. It never creates a thread implicitly: idea/design/plan/req/chat resolve an existing thread and error with a "create it first" hint on a miss, and loom create thread is the sole explicit thread creator.
• The extension-free "Pure agent" way is now complete — full tree management from the terminal. Nine new slug/human-first CLI commands close the gap where a doc op had an MCP tool and an extension button but no terminal twin: archive, restore, delete (TTY-guarded, --yes to bypass), move-thread, set-priority, set-thread-deps, close-plan, quick-ship, and promote --body-file. The whole document graph is now manageable without the VS Code extension.
• loom set-status <doc> <status> — one guarded verb for document status. A single command (mirroring the new loom_set_status tool) handles free label transitions; guarded ones (a plan going to implementing/done, a req to locked) delegate to their owning tool instead of being silently allowed.
• Loom slang — a canonical set of User→AI verbs. A documented vocabulary that maps deterministically to one action so you never spell out the tool: read {path}, reply, do quick, do step {N}, do steps {N,M}/{N-Z}, do plan, docs done, and the quick-fix pair code quick (implements a source change, runs build+test+verify, then records) / write quick (docs-only change, records with no build/test). See loom-slang-reference.md.
• "Ways to Use Loom" guide (docs/WAYS-TO-USE-LOOM.md) — the canonical map of how to run Loom: two users, the control-surface × AI-session-model matrix, and four named recipes (Guided, Power terminal, Pure agent, Automation).

Changed

• One verb model end to end: create / generate / promote. create = an empty doc, generate = AI-authored, promote = a linked transform. The weave{Idea,Design,Plan} use-cases were renamed to create*, the weave-* authoring prompts to generate-* (mirroring loom_generate_*), and the extension adopted Create as its single doc-create label verb. Pure naming; no behavior change, no aliases.
• loom rename now retitles a doc, and rename is a namespace. loom rename <doc> <title> actually retitled, so it is now loom retitle (mirroring loom_retitle); loom rename names a namespace mirroring loom_rename_* — loom rename thread|weave|reference.
• Status changes flow through one path. loom_update_doc no longer accepts a status field (body + requires_load only), and the extension gains a Set Status: Done/Active menu. The redundant pre-ULID loom finalize command and loom_finalize_doc use-case are retired (loom_finalize_req is kept).

Fixed

• Chats can be marked done again. done was dropped as a valid chat status in an earlier refactor; the regression is restored so chats are mark-done-able as before.
• A plan can no longer be marked done behind close_plan's back. Because loom_update_doc accepted a raw status, a plan could be flipped to done bypassing loom_close_plan. Removing status from loom_update_doc closes that latent bypass — the plan→done transition now goes only through its guarded tool.

v1.22.0

Added

• loom install is a safe no-op on a Loom source repo or fork. A repo that hosts Loom's own recursive workflow — this repository, or a fork of it — carries a bespoke CLAUDE.md and must never be overwritten with the generic downstream .loom/CLAUDE.md template. Setting "selfHosting": true in .loom/settings.json now makes every loom install entry point (the CLI, the loom_install MCP tool, and the extension's activation refresh) skip installation entirely and report self-hosting repo — skipped. The guard sits above the --force branch, so even a forced install can't clobber a self-hosting repo's contract.

Changed

• Consistent *Slug naming now reaches the read/query surfaces. Completing the *Ulid/*Slug sweep begun in 1.20.0, every slug-carrying parameter and output key on the consumer surfaces is now *Slug: the loom://state?weaveSlug= filter (was ?weaveId=), and the weaveSlug / threadSlug keys in loom://diagnostics and loom_get_stale_plans output (were weaveId / threadId). Agents or scripts that read those surfaces should switch to the new names — the values and behavior are unchanged, only the names.
• Installed session contract: resolve a pointed-at doc through its slug-path. The .loom/CLAUDE.md template gains a rule that when you point your AI agent at a Loom doc or thread by name or path, it resolves it through the slug-path context resource (loom://context/{weaveSlug}/{threadSlug}/{docSlug}) instead of deriving the ULID by hand — loading the context and resolving the slug→ULID become a single read. Your project picks it up on the next loom install or the extension's activation self-heal.

v1.21.2

Fixed

• .mcp.json no longer breaks standalone terminal agents. 1.21.1 set LOOM_ROOT to ${workspaceFolder}, but that is a VS Code editor variable — a plain claude CLI session (or Cursor, or any non-VS-Code MCP host) can't expand it, so it arrived literally and every loom_* tool failed to resolve paths (with a /mcp "Missing environment variables: workspaceFolder" warning). The server now resolves its own workspace root by walking up from the launch directory to the nearest .loom/, and loom install writes no LOOM_ROOT at all — so a committed .mcp.json is portable and works whether the agent starts at the project root or a subdirectory. An existing ${…} placeholder is silently healed out of .mcp.json on the next loom install, and a subdirectory launch prints a one-line note showing the resolved root.

v1.21.1

Fixed

• loom install writes a portable .mcp.json. The generated MCP config now sets LOOM_ROOT to the ${workspaceFolder} placeholder instead of a resolved absolute path, so a committed .mcp.json is machine-agnostic — it works for every collaborator, and even when the agent is launched from a subdirectory — rather than hard-coding the path of whoever ran loom install. Claude Code and the VS Code MCP-host family expand it to the project root. Existing configs pick it up on loom install --force or the command:"loom" → npx migration.

v1.21.0

Added

• Your AI agent now always runs the exact Loom you have installed. When the VS Code extension launches an AI action, the agent is bound directly to the extension's bundled server (via --strict-mcp-config), so it can't fall out of sync with the extension or run a stale global loom. Any other MCP servers you've configured stay available to the agent.
• Loom keeps itself in sync. Opening a project after an extension update silently refreshes your Loom-owned files — the .loom/CLAUDE.md session contract and the .mcp.json version pin — with no "did I re-run install?" ritual, and without touching your own files (CLAUDE-LOCAL.md, ctx.md, settings).
• One-click migration off the legacy CLI config. If your .mcp.json still points at a global command: "loom" server (the pre-1.19 form), the extension offers to update it to the pinned npx form; loom install --migrate-mcp-command does the same from the terminal.

Changed

• The global loom CLI is retired as a dependency — 1-click, always-current, zero-config. There is now one server codebase and two delivery vehicles — the extension bundle (VS Code) and a pinned npx @reslava/loom@<version> (terminal / Cursor / CI) — and zero persistent global installs. The @reslava/loom npm package still ships; npm i -g is now optional, never required, and never the MCP-server form. READMEs, the CLI guide, and the architecture reference were swept to match.
• The .mcp.json version pin self-heals. On activation the pinned npx version is bumped to the installed version — only for the canonical pinned shape; any custom or local-path config is left untouched.

Fixed

• loom install is idempotent. A byte-identical .loom/CLAUDE.md is no longer rewritten on every install — it neither dirties your git tree nor reports a phantom "written" — and --force reports only what actually changed.

v1.20.0

Added

• loom://catalog now maps the whole agent surface — tools, resources, and prompts. The catalog used to list only loom_* tools; it now groups all three, with a ?kind=tools|resources|prompts filter and a matching loom catalog [kind] CLI command. All three loom://context forms (by doc ULID, by thread slug-path context/thread/{weaveSlug}/{threadSlug}, and by doc slug-path context/{weaveSlug}/{threadSlug}/{docSlug}) are now advertised as first-class resource templates — the two slug-path forms were served but hidden from every MCP client until now.

Changed

• One consistent, model-legible naming scheme across the entire API. Every reference parameter now says what it takes: a ULID reference is *Ulid and a folder/slug reference is *Slug — the ambiguous *Id suffix is gone. Which form a surface speaks follows its consumer: the CLI is slug/human-first (friendly plan and doc refs resolve to a ULID at the edge), the MCP write tools and workflow prompts are strict ULID, and the MCP read/context resources are slug-path human-pointable (e.g. loom://context/{weaveSlug}/{threadSlug}/{docSlug}). Resource-URI placeholders and prompt argument names were renamed to match, and the workflow prompt bodies rewritten to the current tool contract.
• loom resources list folded into loom catalog resources. loom resources read <uri> stays as the generic resource reader.

Fixed

• Unknown blockedBy step references are rejected instead of silently stored. A blockedBy entry that wasn't a valid ordinal, a known step id, or a plan id used to be persisted as a dangling edge that quietly never blocked anything. It now throws, naming the bad value and listing the valid step ids and the ordinal form. The create_plan / add_step / update_step schema descriptions were tightened so agents use ordinals or real step slugs instead of inventing s1-style ids.