akm-cli 0.9.0-beta.42 → 0.9.0-beta.44

package/dist/assets/stash-skeleton/facts/conventions/assets/agent.md

@@ -1,22 +1,38 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for agent assets — edit to taste.
+description: Soft authoring conventions for agent assets using scoped role, tool, and maintenance rules.
 when_to_use: Surfaced to authoring agents when they write or revise an agent asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Agent authoring conventions
 
-An agent is markdown whose frontmatter describes a reusable role.
+An agent asset defines a reusable role. Treat it like a disciplined maintainer, not a generic personality. Its job is to know its scope, read the right rulebooks, use the right tools, and leave the stash in better shape.
 
-- Frontmatter typically carries `name`, `description`, and optionally `tools` and
-  `model`. Write the `description` so a dispatcher knows exactly when to delegate.
-- The body is the system prompt: establish the role, its scope, and its boundaries.
-- Be explicit about what the agent should and should not do, and what it returns.
-- Prefer a focused single-responsibility persona over a broad do-everything agent.
+## Purpose
+
+Use an agent when a recurring task benefits from a specialized role, bounded responsibilities, and explicit tool behavior.
+
+## Authoring strategy
+
+- Write the description so a dispatcher knows exactly when to delegate to this agent.
+- Define the agent’s domain, authority, boundaries, and expected output.
+- Specify what the agent must read first: relevant stash standards, type conventions, reference docs, source files, or prior lessons.
+- State tool expectations plainly: what tools it may use, what it should avoid, and when it must ask for human review.
+- Give the agent maintenance duties when appropriate: update cross-references, append logs, preserve provenance, and surface contradictions.
+- Prefer a narrow role that does one thing reliably over a broad do-everything persona.
+- Include handoff behavior: what the agent should return when it cannot complete the task safely.
+
+## Maintenance strategy
+
+- Refine the agent when repeated sessions show the same delegation failure.
+- Add explicit negative guidance when the agent overreaches.
+- Keep role instructions stable and concise; move large background material into knowledge assets.
+- Use lessons to capture operational improvements, then promote stable ones into the agent when they become part of the role.

package/dist/assets/stash-skeleton/facts/conventions/assets/command.md

@@ -1,22 +1,38 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for command assets — edit to taste.
+description: Soft authoring conventions for command assets using repeatable LLM operation patterns.
 when_to_use: Surfaced to authoring agents when they write or revise a command asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Command authoring conventions
 
-A command is a markdown prompt template the user invokes by name.
+A command is a reusable markdown prompt template invoked by name. Treat it like an operation in the stash: every vague instruction will compound into repeated vague output.
 
-- Optional frontmatter carries `name` and `description`; the body *is* the prompt.
-- Write the body as the instruction you want the model to follow when invoked.
-- State the task, the expected inputs, and the shape of the desired output up front.
-- Keep it tight and unambiguous — a command is run repeatedly, so vagueness compounds.
-- Use clear placeholders for any arguments the caller will supply.
+## Purpose
+
+Use a command when the user or agent needs to perform the same prompt-shaped task repeatedly with different arguments or context.
+
+## Authoring strategy
+
+- Put the task, inputs, constraints, and expected output shape near the top.
+- Make argument placeholders obvious and describe what each one should contain.
+- Tell the model what to inspect before acting, especially relevant stash assets, facts, standards, or reference docs.
+- State the decision boundary: what the command should do directly, what it should only propose, and what it should refuse or defer.
+- Include output requirements that are stable across runs.
+- Keep the prompt tight. A command should be easy to invoke and hard to misinterpret.
+- Avoid embedding one-time project details unless the command is intentionally project-specific.
+
+## Maintenance strategy
+
+- If users repeatedly clarify the same missing detail, add that detail to the command.
+- If command output regularly becomes useful durable knowledge, instruct the agent to file the result into the right asset type.
+- If the command starts handling multiple unrelated tasks, split it into smaller commands.
+- Preserve a clear invocation contract so future agents can call the command safely.

package/dist/assets/stash-skeleton/facts/conventions/assets/fact.md

@@ -1,24 +1,39 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for fact assets — edit to taste.
+description: Soft authoring conventions for fact assets using pinned-core and just-in-time context principles.
 when_to_use: Surfaced to authoring agents when they write or revise a fact asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Fact authoring conventions
 
-A fact is durable stash-level context — personal, team, or project details,
-coding conventions, or stash-meta.
+A fact is durable stash-level context: personal, team, project, convention, or meta knowledge. Treat facts as the stash’s semantic layer — selectively loaded context that should guide future work without bloating every prompt.
 
-- Frontmatter should include a `description` and a `category`
-  (personal | team | project | convention | meta).
-- Set `pinned: true` only for the small always-injected core; most facts stay unpinned.
-- Keep each fact short, high-signal, and self-contained — it is durable context,
-  not an episodic note.
-- Write it as a standing declaration that stays true across sessions.
+## Purpose
+
+Use a fact for stable information that future agents should treat as true or normative: user preferences, project identity, team stack, architecture principles, naming conventions, tag vocabulary, or stash organization.
+
+## Authoring strategy
+
+- Write each fact as a standing declaration that can survive across sessions.
+- Keep it short, high-signal, and self-contained.
+- Choose the narrowest useful category: personal, team, project, convention, or meta.
+- Use `pinned: true` only for the small core that should be available constantly.
+- Leave most facts unpinned so they can be retrieved just-in-time.
+- Include scope and provenance when a fact is project-specific, inferred, or subject to change.
+- Separate facts from memories: memories preserve observations; facts state durable truth or durable policy.
+- Separate facts from knowledge: knowledge explains a topic; facts declare compact context.
+
+## Maintenance strategy
+
+- Revise or supersede facts when the durable truth changes.
+- Do not allow contradictory facts to remain equally active.
+- Promote repeated memories or lessons into facts only when they become stable context.
+- Keep convention and meta facts especially clear, because they steer future asset creation.

package/dist/assets/stash-skeleton/facts/conventions/assets/knowledge.md

@@ -1,22 +1,40 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for knowledge assets — edit to taste.
+description: Soft authoring conventions for knowledge assets as compiled, on-demand reference documents.
 when_to_use: Surfaced to authoring agents when they write or revise a knowledge asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Knowledge authoring conventions
 
-A knowledge asset is a reference document meant to be read on demand.
+A knowledge asset is a compiled reference document meant to be read on demand. Treat it as the synthesized layer above raw material: not source files, not chat residue, but integrated, navigable understanding that saves future agents from rediscovering the same material.
 
-- Open with a top-level `# Title` that names the subject plainly.
-- Organise into concise, well-headed sections so a reader can jump to what they need.
-- Favour accuracy and clarity over completeness; link or cross-reference rather than
-  duplicating other assets.
-- Voice: explanatory and neutral, written to be re-read months later.
+## Purpose
+
+Use a knowledge asset for durable reference material, synthesized explanations, design notes, comparisons, and project context that is broader than a single memory but less procedural than a skill.
+
+## Authoring strategy
+
+- Open with a plain top-level title that names the subject.
+- Add a concise orientation paragraph: what this document covers and when it should be read.
+- For a long reference, add a table of contents near the top so the full scope is visible even on a partial read.
+- Organize by stable concepts, decisions, entities, or questions — roughly one page per concept.
+- Cross-reference related assets instead of duplicating them, so a navigable graph forms over time.
+- Preserve provenance where it matters: cite source files, raw notes, session logs, or issues by path/ref.
+- Call out contradictions, uncertainty, stale claims, and open questions explicitly.
+- Prefer accurate synthesis over exhaustive dumping. Raw material belongs elsewhere; this file is the compiled layer.
+- Use tables or checklists when they make retrieval and comparison easier.
+
+## Maintenance strategy
+
+- Update the existing page when new information changes the same topic; append a dated note rather than silently rewriting when provenance matters.
+- Create a new page when the concept deserves its own durable entry.
+- Add links both ways when a new relationship matters.
+- Periodically scan for orphaned, stale, or overlapping knowledge docs and consolidate them.

package/dist/assets/stash-skeleton/facts/conventions/assets/lesson.md

@@ -1,25 +1,43 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for lesson assets — edit to taste.
+description: Soft authoring conventions for lesson assets that capture compounding, hard-won judgment.
 when_to_use: Surfaced to authoring agents when they write or revise a lesson asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate. Tune the guidance below to match
-  how your stash likes lessons written.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Lesson authoring conventions
 
-A lesson captures durable, hard-won judgement about *when* to reach for something
-and *what goes wrong without it* — it is not a restatement of the source asset.
+A lesson captures durable, hard-won judgment that should compound across future agent sessions. Treat it as distilled judgment about how to act: it should preserve the extracted meaning of what real use revealed, not merely recount an incident or summarize another asset.
 
-- Lead with the trigger: when should a reader reach for this lesson?
-- Then the failure mode: what breaks, or what gets missed, without it?
-- Then the insight: what did real use reveal that the asset itself does not say?
-- Keep it to one to three short, concrete paragraphs. Prefer specifics over
-  general advice; a lesson earns its keep by being actionable in a real moment.
-- Voice: direct and practical, written for a future agent mid-task.
+## Purpose
+
+Use a lesson to record:
+
+- when to reach for a pattern, asset, or decision;
+- what tends to go wrong without it;
+- what evidence, feedback, or repeated experience made the lesson worth keeping;
+- how a future agent should act differently because this lesson exists.
+
+## Authoring strategy
+
+- Lead with the trigger: the concrete situation where this lesson should be loaded.
+- Follow with the failure mode: what mistake, omission, or confusion this prevents.
+- End with the reusable judgment: the practical rule a future agent can apply.
+- Keep the scope narrow. A lesson should teach one durable behavior.
+- Prefer observed evidence over generic advice. Mention the kind of signal that produced the lesson, such as rejected proposals, repeated lint findings, user feedback, or session outcomes.
+- Do not restate the source asset. Lessons are compiled judgment, not copied documentation.
+- Write for a future agent mid-task: direct, practical, and easy to apply.
+
+## Maintenance strategy
+
+- Update an existing lesson when new feedback sharpens the same judgment.
+- Create a new lesson only when the trigger or failure mode is meaningfully different.
+- Deprecate or revise stale lessons instead of allowing contradictory guidance to accumulate.
+- When a lesson becomes broadly normative, consider promoting the stable rule into a `fact:conventions/...` asset.

package/dist/assets/stash-skeleton/facts/conventions/assets/memory.md

@@ -1,21 +1,38 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for memory assets — edit to taste.
+description: Soft authoring conventions for memory assets using durable-context and provenance discipline.
 when_to_use: Surfaced to authoring agents when they write or revise a memory asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Memory authoring conventions
 
-A memory is a short factual note the user wants persisted across sessions.
+A memory is a short, durable note that should survive beyond the current session. Treat it as a small compiled fact or decision, not a transcript fragment.
 
-- Frontmatter usually includes a `description` that states the fact in one line.
-- Keep the body brief and self-contained — one durable fact or decision per memory.
-- Write it so it still reads clearly with no surrounding conversation for context.
-- Prefer durable, reusable facts over episodic play-by-play of a single session.
+## Purpose
+
+Use a memory when a future agent would make a better decision by knowing a specific user preference, project decision, environmental fact, constraint, or observed outcome.
+
+## Authoring strategy
+
+- Record one durable fact, decision, or constraint per memory.
+- Write it so it stands alone without the original conversation.
+- Include enough context to prevent misapplication: subject, scope, and when it matters.
+- Prefer stable, reusable information over step-by-step session play-by-play.
+- Mark uncertainty or subjectivity clearly when the memory is not a settled fact.
+- Preserve source/provenance in frontmatter or body when the memory came from a session, log, user statement, or derived inference.
+- Avoid storing secrets, private tokens, or volatile temporary state as memory.
+
+## Maintenance strategy
+
+- Update or supersede memories when newer evidence changes the truth.
+- Consolidate repeated memories into a clearer fact or knowledge asset.
+- Convert broad, stable conventions into `fact` assets.
+- Archive memories that are no longer current rather than letting stale context keep influencing agents.

package/dist/assets/stash-skeleton/facts/conventions/assets/script.md

@@ -1,21 +1,43 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for script assets — edit to taste.
+description: Soft authoring conventions for script assets using agent-safe CLI helper principles.
 when_to_use: Surfaced to authoring agents when they write or revise a script asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Script authoring conventions
 
-A script is an executable text file stored as-is and run on demand.
+A script is an executable helper that an agent or human can run on demand. Treat it like a small, deterministic tool that reduces manual bookkeeping and makes repeatable operations safer.
 
-- Start with a shebang appropriate to the interpreter (e.g. `#!/usr/bin/env bash`).
-- Follow it with a short usage comment: what the script does and how to invoke it.
-- Keep the script focused on one job; fail loudly and early on bad input.
-- Prefer readable, well-commented logic over cleverness — these get re-run by others.
+## Purpose
+
+Use a script when a task is mechanical, repeatable, and better handled by a deterministic program than by free-form agent edits.
+
+## Authoring strategy
+
+- Start with the appropriate interpreter line and a short usage comment.
+- State what the script does, expected inputs, outputs, side effects, and failure behavior.
+- Keep one script focused on one job.
+- Validate inputs before mutation.
+- Fail loudly and early on unsafe or ambiguous input.
+- Declare required dependencies and assumptions explicitly rather than assuming a tool is installed.
+- Justify any non-obvious constant (timeout, retry count, limit) in a comment so a future reader can adjust it safely.
+- Prefer idempotent behavior where practical.
+- Avoid hidden network calls, destructive defaults, or silent writes.
+- Never print secrets or sensitive values.
+- Write output that is easy for both humans and agents to parse.
+- Favor clear names, straightforward control flow, and comments at decision points.
+
+## Maintenance strategy
+
+- Add examples when agents or users repeatedly invoke the script incorrectly.
+- Keep dangerous actions behind explicit flags.
+- When a script becomes a core operation, add or update a workflow that explains when to run it.
+- If the script encodes a convention, also document that convention in a fact or knowledge asset.

package/dist/assets/stash-skeleton/facts/conventions/assets/skill.md

@@ -1,23 +1,40 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for skill assets — edit to taste.
+description: Soft authoring conventions for skill assets as reusable, just-in-time procedural rulebooks.
 when_to_use: Surfaced to authoring agents when they write or revise a skill asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Skill authoring conventions
 
-A skill is a reusable, self-contained capability stored as `skills/<name>/SKILL.md`.
+A skill is a reusable, self-contained capability stored as `skills/<name>/SKILL.md`. Treat it like a compact operating manual that an agent can load just-in-time, follow without rediscovering the process, and improve when repeated use exposes gaps.
 
-- Frontmatter usually carries `name`, `description`, and `when_to_use`. Write the
-  `description` so a dispatcher can decide *from it alone* whether to load the skill.
-- Open the body with the goal in an imperative voice ("Generate…", "Review…").
-- Structure as: purpose, when to use, then the procedure or guidance as ordered
-  steps or short sections. Favour scannable headings over long prose.
-- Keep it focused on one capability; split unrelated concerns into separate skills.
+## Purpose
+
+Use a skill when the stash needs reusable procedural guidance for a recurring class of work. A good skill reduces repeated reasoning cost: future agents should not have to reconstruct the same method from raw context.
+
+## Authoring strategy
+
+- Make the dispatch signal clear. The description should let a dispatcher decide whether to load the skill without reading the whole body.
+- Open with the outcome the skill helps produce.
+- State when to use it, when not to use it, and what inputs the agent should gather before acting.
+- Structure the body as a rulebook: principles first, then procedure, then checks.
+- Use short sections and ordered steps where sequence matters.
+- Match the level of detail to how fragile the task is: open-ended work gets high-level heuristics and room to reason, while fragile or consistency-critical steps get exact, unambiguous instructions.
+- Keep the body lean and move bulky background into companion knowledge docs referenced one level deep, so the skill loads cheaply and stays scannable.
+- Include failure modes and verification steps. A skill should tell the agent how to know the work is complete.
+- Keep one skill focused on one capability. Split unrelated concerns into separate skills and cross-reference them.
+
+## Maintenance strategy
+
+- Update the skill when session logs, feedback, or rejected proposals reveal repeatable confusion.
+- Add companion knowledge docs when the skill needs background material that would bloat the main procedure.
+- Promote durable recurring corrections into the skill; leave one-off observations in memories or lessons.
+- Prefer small edits that preserve the skill’s operational shape over broad rewrites that erase tested guidance.

package/dist/assets/stash-skeleton/facts/conventions/assets/workflow.md

@@ -1,22 +1,43 @@
 ---
 category: convention
-description: Starter SOFT authoring conventions for workflow assets — edit to taste.
+description: Soft authoring conventions for workflow assets using explicit operations, logging, and lintable steps.
 when_to_use: Surfaced to authoring agents when they write or revise a workflow asset.
 ---
 
 <!--
   SOFT guidance only — advice, not a contract. Nothing here is enforced by the
-  proposal gate; the validator-rejecting HARD rules live in
-  src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
-  or deleting this file cannot weaken the gate.
+  proposal gate; validator-rejecting HARD rules live in src/core/authoring-rules.ts
+  and remain the sole enforced source. Editing or deleting this file cannot weaken
+  the gate. Tune the guidance below to match how your stash wants this asset type
+  maintained.
 -->
 
 # Workflow authoring conventions
 
-A workflow describes a multi-step process an agent or human follows in order.
+A workflow describes an ordered process an agent or human can follow. Treat it as the operation layer of a maintained stash: clear steps, clear state, clear completion criteria, and enough bookkeeping to resume safely.
 
-- Open with a top-level `# <Title>` naming the workflow's outcome.
-- Lay out the steps as ordered `## Step N` sections, each with a clear action.
-- For each step, state what to do, what it depends on, and how to know it is done.
-- Keep steps atomic and resumable — a reader should be able to stop and pick up midway.
-- Note any branch points or preconditions explicitly rather than burying them in prose.
+## Purpose
+
+Use a workflow when the task requires multiple steps, branching decisions, repeated checks, or durable progress tracking.
+
+## Authoring strategy
+
+- Open with the outcome the workflow produces.
+- State prerequisites, required inputs, and tools before the steps.
+- Use ordered step sections when sequence matters.
+- For each step, specify:
+  - what to do;
+  - what evidence or input it depends on;
+  - what output it produces;
+  - how to know the step is done.
+- Make branch points explicit. Do not bury conditional behavior in prose.
+- Include validation, lint, or review steps near the end.
+- Include rollback or recovery notes when the workflow mutates files, state, repos, or external systems.
+- Keep steps atomic and resumable so an interrupted run can continue without guessing.
+
+## Maintenance strategy
+
+- Update the workflow when repeated execution reveals missing checks or unclear handoffs.
+- Add logging expectations when the workflow creates durable state.
+- Extract reusable sub-procedures into skills or scripts when the workflow grows too broad.
+- Record recurring mistakes as lessons, then fold stable corrections back into the workflow.

package/dist/commands/improve/improve.js

@@ -964,6 +964,63 @@ export async function akmImprove(options = {}) {
     // #576: clears the per-run LLM usage sink. Defaults to a no-op until the sink
     // is installed inside the try; the `finally` always calls it.
     let disposeLlmUsageSink = () => { };
+    // ── Crash-safe / incremental stash sync (#662) ──────────────────────────────
+    // The primary stash writes as a filesystem source DURING the run
+    // (write-source.ts case-3); those writes become a git commit only when this
+    // closure runs. Historically the only call site was a single BATCH commit at
+    // the very end of the happy path, so a run interrupted AFTER writing but
+    // BEFORE finishing — a mid-cycle crash, a budget abort, or an external
+    // SIGTERM/`process.exit` — left every write uncommitted until some LATER run
+    // happened to finish cleanly and swept the whole backlog up. We now call this
+    // from THREE places: between cycles (bank each completed cycle), at end-of-run
+    // (the converged commit), and from the catch path (commit what was written
+    // before the crash). That shrinks the worst-case loss from "the entire run" to
+    // "the in-flight cycle".
+    //
+    // Declared in the OUTER scope (not inside the try) so the catch block can reach
+    // it. Idempotent + NON-FATAL: `saveGitStash` short-circuits a clean working
+    // tree ("nothing to commit") and a thrown sync error is swallowed here, so a
+    // repeat call after a no-op cycle is cheap and a failed push never fails the
+    // run. Gated identically to the original end-of-run block (git-backed primary
+    // stash, sync not disabled). `eventsCtx` is captured by reference, so calls
+    // after the db-backed context is installed inside the try use the live handle.
+    const effectiveSync = { ...improveProfile.sync, ...options.sync };
+    const commitStashBatch = (messageContext) => {
+        if (!primaryStashDir || effectiveSync.enabled === false || !isGitBackedStash(primaryStashDir)) {
+            return undefined;
+        }
+        const saveGitStashFn = options.saveGitStashFn ?? saveGitStash;
+        const writableOverride = resolveWritableOverride(_earlyConfig);
+        const push = effectiveSync.push !== false;
+        const message = renderSyncCommitMessage(effectiveSync.message ?? "akm improve auto-sync", messageContext, Date.now());
+        try {
+            const syncResult = saveGitStashFn(undefined, message, writableOverride, { push, repoDir: primaryStashDir });
+            appendEvent({
+                eventType: "stash_synced",
+                metadata: {
+                    committed: syncResult.committed,
+                    pushed: syncResult.pushed,
+                    skipped: syncResult.skipped,
+                    reason: syncResult.reason ?? null,
+                },
+            }, eventsCtx);
+            return {
+                committed: syncResult.committed,
+                pushed: syncResult.pushed,
+                skipped: syncResult.skipped,
+                ...(syncResult.reason !== undefined ? { reason: syncResult.reason } : {}),
+            };
+        }
+        catch (syncErr) {
+            const reason = syncErr instanceof Error ? syncErr.message : String(syncErr);
+            warn(`improve: stash sync failed (non-fatal): ${reason}`);
+            appendEvent({
+                eventType: "stash_synced",
+                metadata: { committed: false, pushed: false, skipped: true, reason },
+            }, eventsCtx);
+            return { committed: false, pushed: false, skipped: true, reason };
+        }
+    };
     try {
         // H7 (#566): arm the budget watchdog. `armBudgetWatchdog` captures both the
         // budget timer and the hard-kill timer it schedules on exhaustion, returning
@@ -1053,6 +1110,16 @@ export async function akmImprove(options = {}) {
                     break;
                 }
             }
+            // #662 incremental sync: bank the PREVIOUS cycle's writes before starting a
+            // new one, so a crash/abort/timeout mid-run loses at most the in-flight
+            // cycle rather than the whole run. Guarded on `cycleIndex > 0`, so the
+            // common maxCycles:1 path never calls this — its single end-of-run commit
+            // below stays the only sync and the serialized envelope is byte-identical
+            // to pre-#662. `saveGitStash` no-ops a clean tree, so a cycle that wrote
+            // nothing costs only a `git status`.
+            if (cycleIndex > 0) {
+                commitStashBatch({ scope, plannedRefs, runId: options.runId });
+            }
             // Re-run ensureIndex + collectEligibleRefs + memory-cleanup recompute for
             // cycles 2+ (cycle 1 already ran them in the first try above). This makes
             // cycle N's gate-promoted proposals visible to this cycle's ref selection.
@@ -1309,57 +1376,18 @@ export async function akmImprove(options = {}) {
                 warningCount: allWarnings.length,
                 orphansPurged: orphansPurged ?? 0,
             }, eventsCtx);
-        // End-of-run BATCH auto-sync. Recognition is decoupled from the per-write
-        // path (see write-source.ts case-3): the primary stash writes as a
-        // filesystem source during the run, then is committed in one shot here via
-        // the same `saveGitStash` that `akm sync` calls. Gated on a non-dry-run, a
-        // git-backed primary stash (by `.git`, not by remote), and sync not
-        // disabled. A sync failure is NON-FATAL — it never fails a successful run
-        // (mirrors the contradiction-detection best-effort pattern).
-        const effectiveSync = { ...improveProfile.sync, ...options.sync };
-        if (!result.dryRun && primaryStashDir && effectiveSync.enabled !== false && isGitBackedStash(primaryStashDir)) {
-            const saveGitStashFn = options.saveGitStashFn ?? saveGitStash;
-            // Reuse the config resolved at the top of the run (`_earlyConfig`) instead
-            // of a second loadConfig(); the writable derivation is shared with
-            // `akm sync` via resolveWritableOverride().
-            const writableOverride = resolveWritableOverride(_earlyConfig);
-            const push = effectiveSync.push !== false;
-            // `sync.message` may contain `{token}` placeholders (timestamp/date/time/
-            // scope/refs/accepted) expanded against this run's results; the default
-            // template has no tokens so it renders verbatim.
-            const message = renderSyncCommitMessage(effectiveSync.message ?? "akm improve auto-sync", result, Date.now());
-            try {
-                // Pass primaryStashDir as the explicit commit target so the gate above
-                // (which validated primaryStashDir via isGitBackedStash) and the commit
-                // operate on the SAME directory — avoids divergence when a caller passes
-                // a non-default options.stashDir (FIX 9).
-                const syncResult = saveGitStashFn(undefined, message, writableOverride, { push, repoDir: primaryStashDir });
-                result.sync = {
-                    committed: syncResult.committed,
-                    pushed: syncResult.pushed,
-                    skipped: syncResult.skipped,
-                    ...(syncResult.reason !== undefined ? { reason: syncResult.reason } : {}),
-                };
-                appendEvent({
-                    eventType: "stash_synced",
-                    metadata: {
-                        committed: syncResult.committed,
-                        pushed: syncResult.pushed,
-                        skipped: syncResult.skipped,
-                        reason: syncResult.reason ?? null,
-                    },
-                }, eventsCtx);
-            }
-            catch (syncErr) {
-                const reason = syncErr instanceof Error ? syncErr.message : String(syncErr);
-                warn(`improve: end-of-run stash sync failed (non-fatal): ${reason}`);
-                result.sync = { committed: false, pushed: false, skipped: true, reason };
-                appendEvent({
-                    eventType: "stash_synced",
-                    metadata: { committed: false, pushed: false, skipped: true, reason },
-                }, eventsCtx);
-            }
-        }
+        // End-of-run BATCH auto-sync — the converged commit. Recognition is
+        // decoupled from the per-write path (see write-source.ts case-3): the primary
+        // stash writes as a filesystem source during the run, then is committed via
+        // the same `saveGitStash` that `akm sync` calls. The gating (git-backed
+        // primary stash, sync not disabled) and the NON-FATAL guarantee now live in
+        // `commitStashBatch` (#662); the inter-cycle and catch-path calls reuse it.
+        // dry-run already returned above, so this always runs on a completed live
+        // run. `result.sync` reflects this final commit (for a one-cycle run it is
+        // the only commit; for a multi-cycle run the earlier cycles were banked by
+        // the inter-cycle calls and this records the last batch). `result` carries
+        // the full `{accepted}`/`{refs}`/`{triage_*}` token data for the message.
+        result.sync = commitStashBatch(result);
         return result;
     }
     catch (err) {
@@ -1372,6 +1400,13 @@ export async function akmImprove(options = {}) {
                 durationMs: Date.now() - startMs,
             },
         }, eventsCtx);
+        // #662 crash/abort safety net: commit whatever this run already wrote to the
+        // primary stash BEFORE rethrowing, so an interrupted run (mid-cycle crash or
+        // a cooperative budget abort that surfaces as a throw) does not leave its
+        // writes uncommitted until a later clean run sweeps them up. Best-effort —
+        // `commitStashBatch` swallows its own errors and no-ops a clean tree, so this
+        // never masks or supersedes the original failure being rethrown below.
+        commitStashBatch({ scope, plannedRefs, runId: options.runId });
         throw err;
     }
     finally {
@@ -3952,6 +3987,7 @@ async function runImprovePostLoopStage(args) {
                 // #632 — clustering-tuning knobs. UNSET = pre-#632 behaviour.
                 maxClusterSize: improveProfile.processes?.recombine?.maxClusterSize,
                 excludeTags: improveProfile.processes?.recombine?.excludeTags,
+                excludeEntities: improveProfile.processes?.recombine?.excludeEntities,
             });
         }
         catch (e) {

package/dist/commands/improve/recombine.js

@@ -57,7 +57,27 @@ import { isConsolidationEligibleMemoryName } from "./consolidate.js";
 const RECOMBINE_SYSTEM_PROMPT = recombineSystemPrompt;
 const DEFAULT_MIN_CLUSTER_SIZE = 3;
 const DEFAULT_MAX_CLUSTERS_PER_RUN = 5;
-const DEFAULT_RELATEDNESS_SOURCE = "tags";
+// #632 — slots in each run's processed budget reserved for the top TAG clusters
+// when entity clusters are present, so tag-only topics (a topic with a good tag
+// but no extracted graph entity) are never fully starved by entity preference.
+// Entities still take the rest of the budget; whichever kind is short, the other
+// backfills. UNSET of entities (tags-only stash) ignores this and takes top-N tags.
+const RESERVED_TAG_SLOTS = 3;
+// #632 — a tag cluster larger than this is treated as an over-broad project
+// mega-bucket (low-coherence, the bland signal #632 de-emphasizes), so the
+// reserved tag slots prefer TIGHTER clusters at or below this size first.
+const TAG_RESERVE_SOFT_CAP = 20;
+// #632 — default to the UNION of tag + graph-entity relatedness, with entity
+// clusters PREFERRED at selection time (see the rank in buildRelatednessClusters).
+// Entity clustering surfaces coherent, subject-scoped clusters (a tool/subsystem)
+// that the coarse stash-wide tag buckets miss, while tags still cover memories the
+// graph has no entity for. The `entity:` vs `tag:` signature namespaces are
+// independent, so a pure tag cluster's confirmation streak is only re-baselined
+// when its OWN membership changes — which is exactly what the session-capture pool
+// exclusion intends for the telemetry-polluted buckets (re-baselining a noisy
+// cluster's streak is correct, not a regression). A stash with no extracted graph
+// entities falls through to tag-only.
+const DEFAULT_RELATEDNESS_SOURCE = "both";
 /** #625 — re-induction count required before a hypothesis promotes to a lesson. */
 const DEFAULT_CONFIRM_THRESHOLD = 2;
 /**
@@ -131,6 +151,76 @@ export function isJunkTag(tag) {
         return true; // short hex hashes: 002c624c, 192d
     return false;
 }
+/**
+ * #632 — generic extraction-artefact entities the graph routinely emits: session
+ * bookkeeping (`session_id`, `session_checkpoint`), structured-log field names
+ * (`reason`, `harness`, `structured event log`), and the like. They are
+ * stash-wide and carry no topical signal, so an `entity:<norm>` cluster keyed on
+ * one is exactly the bland mega-bucket #632 aims to remove. Lowercased; matched
+ * against the already-normalised `entity_norm`.
+ */
+const JUNK_ENTITY_NORMS = new Set([
+    "session",
+    "session_id",
+    "session_checkpoint",
+    "checkpoint",
+    "reason",
+    "harness",
+    "event",
+    "event log",
+    "structured event",
+    "structured event log",
+    "timestamp",
+    "metadata",
+    "status",
+]);
+/**
+ * #632 — AKM session-capture telemetry memories: auto-generated session-end
+ * checkpoints named `<harness>-session-<YYYYMMDD>-<id>` or
+ * `<harness>-checkpoint-<YYYYMMDD…>-<id>`, carrying an embedded
+ * `akm_memory_kind: session_checkpoint` metadata block. Their bodies are
+ * pipeline bookkeeping, so the graph extracts their metadata FIELDS
+ * (`session_checkpoint`, `harness`, `buffered observations`, `tool_*_observed`,
+ * …) as ENTITIES — which then dominate entity clustering as bland, stash-wide
+ * mega-buckets (the #632 symptom, just under an `entity:` signature). They are
+ * session telemetry, not durable knowledge to generalize, so recombine excludes
+ * them from its pool. The `\d{8}` datestamp anchor is what distinguishes a
+ * capture name from a durable memory that merely MENTIONS session/checkpoint
+ * (e.g. `akm-plugins-session-end-extract-hook`, `session-checkpoint-lint-skips`),
+ * which stay in the pool.
+ */
+export function isSessionCaptureMemoryName(name) {
+    return /-(session|checkpoint)-\d{8}/.test(name);
+}
+/**
+ * #632 — an entity carries no clustering signal (and must be skipped) when it is
+ * a generic extraction artefact (session / structured-log bookkeeping), a raw
+ * filesystem path (absolute paths the extractor lifts verbatim), or the same
+ * number / date / hash / version / stopword junk `isJunkTag` rejects. Mirrors
+ * `isJunkTag` so the graph relatedness source does not reintroduce the very
+ * bland buckets entity clustering is meant to replace. Unlike `excludeEntities`
+ * (a fixed user list), this catches the OPEN-ENDED junk without config upkeep.
+ */
+export function isJunkEntity(entity) {
+    const e = entity.trim().toLowerCase();
+    if (e.length <= 1)
+        return true;
+    if (JUNK_ENTITY_NORMS.has(e))
+        return true;
+    if (JUNK_STOPWORD_TAGS.has(e))
+        return true;
+    if (e.includes("/") || e.includes("\\"))
+        return true; // raw file paths
+    if (/^\d+$/.test(e))
+        return true; // pure numbers + dates
+    if (/^v?\d+(?:\.\d+)+$/.test(e))
+        return true; // versions
+    if (/^v\d+$/.test(e))
+        return true; // v0, v2
+    if (/^[0-9a-f]{4,}$/.test(e) && /\d/.test(e))
+        return true; // short hex hashes
+    return false;
+}
 /**
  * Build relatedness clusters from the memory pool. Clustering is driven purely
  * by shared tags / graph entities — it MUST NOT use embedding similarity, so
@@ -146,13 +236,19 @@ export function isJunkTag(tag) {
  * A cluster is a signal whose member set is >= `minClusterSize`. Overlapping
  * clusters are de-duplicated by member-set identity, and the result is RANKED
  * by member-count descending (deterministic alphabetical tiebreak). The
- * `maxClustersPerRun` cap is NOT applied here — call {@link capClusters} on the
- * result for the processed slice; the full ranked list is retained so the
- * cap-aware decay sweep can tell cap-displacement from corpus absence (#658).
+ * `maxClustersPerRun` cap is NOT applied here — call {@link selectClustersForRun}
+ * (entity-aware blend) or {@link capClusters} (tags-only) on the result for the
+ * processed slice; the full ranked list is retained so the cap-aware decay sweep
+ * can tell cap-displacement from corpus absence (#658).
  */
 export function buildRelatednessClusters(entries, opts) {
     // Only consolidation-eligible memories participate (exclude `.derived`).
-    const memories = entries.filter((e) => e.entry.type === "memory" && isConsolidationEligibleMemoryName(e.entry.name));
+    // #632 — durable memories only: exclude `.derived` (via
+    // `isConsolidationEligibleMemoryName`) AND session-capture telemetry dumps
+    // whose embedded metadata pollutes both tag and entity clustering.
+    const memories = entries.filter((e) => e.entry.type === "memory" &&
+        isConsolidationEligibleMemoryName(e.entry.name) &&
+        !isSessionCaptureMemoryName(e.entry.name));
     // signal -> member entries
     const groups = new Map();
     const add = (signal, entry) => {
@@ -173,9 +269,13 @@ export function buildRelatednessClusters(entries, opts) {
     const hasEntities = !!opts.entityByEntryId && opts.entityByEntryId.size > 0;
     const useGraph = (opts.relatednessSource === "graph" || opts.relatednessSource === "both") && hasEntities;
     const tagsFallback = !useTags && opts.relatednessSource === "graph" && !hasEntities;
-    // #632 — tags excluded from tag-based clustering (applies regardless of
-    // source). UNSET/[] leaves clustering byte-identical to the pre-#632 path.
+    // #632 — tags/entities excluded from clustering (applies regardless of
+    // source). UNSET/[] leaves tag clustering byte-identical to the pre-#632 path.
     const excludeTags = new Set(opts.excludeTags ?? []);
+    // `entity_norm` is always lowercased (graph-dedup.ts), so normalise the
+    // user-supplied exclusion list to match — `excludeEntities: ["OpenCode"]`
+    // should suppress the stored `opencode` entity (Reviewer A, #632).
+    const excludeEntities = new Set((opts.excludeEntities ?? []).map((e) => e.toLowerCase()));
     for (const entry of memories) {
         if (useTags || tagsFallback) {
             for (const tag of entry.entry.tags ?? []) {
@@ -187,8 +287,13 @@ export function buildRelatednessClusters(entries, opts) {
             }
         }
         if (useGraph && opts.entityByEntryId) {
-            for (const ent of opts.entityByEntryId.get(entry.id) ?? [])
+            for (const ent of opts.entityByEntryId.get(entry.id) ?? []) {
+                if (excludeEntities.has(ent))
+                    continue;
+                if (isJunkEntity(ent))
+                    continue; // #632 — skip generic extraction-artefact / path entities
                 add(`entity:${ent}`, entry);
+            }
         }
     }
     // Keep only groups at or above the minimum cluster size. #632 — when
@@ -216,12 +321,25 @@ export function buildRelatednessClusters(entries, opts) {
         seenMemberKeys.add(memberKey);
         return true;
     });
-    // Rank largest-first (deterministic alphabetical tiebreak). The cap is applied
-    // by the caller via {@link capClusters}, NOT here, so the FULL formed set
-    // (every cluster that genuinely re-forms this run) stays available for the
-    // cap-aware decay sweep — a cluster displaced by the cap must not be confused
-    // with a cluster that vanished from the corpus (#658).
-    clusters.sort((a, b) => b.members.length - a.members.length || a.signature.localeCompare(b.signature));
+    // #632 — rank ENTITY clusters ahead of tag clusters, then largest-first within
+    // each kind (deterministic alphabetical tiebreak). A graph entity is an
+    // EXTRACTED SUBJECT (a tool / subsystem / component), so it is a far
+    // higher-signal cluster key than an auto-tokenized frontmatter tag, whose
+    // broadest buckets (`tag:<project>` — e.g. every memory tagged `akm`) are the
+    // coarse, bland clusters #632 set out to kill. Largest-first ALONE let those
+    // tag mega-buckets fill the `maxClustersPerRun` slice every run and starve the
+    // coherent entity clusters this pass produces. Preferring entities keeps tag
+    // clustering as the fallback (a stash with no graph entities, or a topic with a
+    // tag but no extracted entity, still clusters) while ensuring the better signal
+    // wins the cap. The processed slice is chosen by the caller via
+    // {@link selectClustersForRun} (NOT here), so the FULL formed set stays
+    // available for the cap-aware decay sweep —
+    // a cluster displaced by the cap must not be confused with a cluster that
+    // vanished from the corpus (#658).
+    const entityRank = (sig) => (sig.startsWith("entity:") ? 0 : 1);
+    clusters.sort((a, b) => entityRank(a.signature) - entityRank(b.signature) ||
+        b.members.length - a.members.length ||
+        a.signature.localeCompare(b.signature));
     return clusters;
 }
 /**
@@ -235,6 +353,54 @@ export function buildRelatednessClusters(entries, opts) {
 export function capClusters(ranked, maxClustersPerRun) {
     return ranked.slice(0, Math.max(0, maxClustersPerRun));
 }
+/**
+ * #632 — pick the per-run PROCESSED slice from the full ranked list, BLENDING
+ * entity and tag clusters so neither starves the other:
+ *
+ *   - No entity clusters → top `maxClustersPerRun` TAG clusters (a tags-only
+ *     stash is byte-identical to {@link capClusters}).
+ *   - Entity clusters present → ENTITIES LEAD the budget (the higher-signal key —
+ *     an extracted subject vs an auto-tokenized filename tag), but RESERVE up to
+ *     `RESERVED_TAG_SLOTS` for tag clusters so tag-only topics still surface every
+ *     run. Entities are never starved below one slot when present and the budget
+ *     allows. Whichever kind is short, the other backfills, so the full budget is
+ *     always used when enough clusters exist.
+ *
+ * The reserved tag slots prefer TIGHTER tag clusters (size <= `TAG_RESERVE_SOFT_CAP`,
+ * largest-first within that band, then the over-cap buckets): a broad
+ * auto-tokenized `tag:<project>` mega-bucket is exactly the bland, low-coherence
+ * signal #632 de-emphasizes, so the reserve should not spend its protected slots
+ * on the largest tags. Entities themselves stay largest-first — an entity is a
+ * coherent subject at any size.
+ *
+ * Entities lead the returned order. The FULL pre-cap `ranked` list (not this
+ * slice) still feeds the cap-aware decay sweep (#658), so a cluster left out of
+ * the processed slice this run is NOT decayed as if it vanished.
+ */
+export function selectClustersForRun(ranked, maxClustersPerRun) {
+    const max = Math.max(0, maxClustersPerRun);
+    if (max === 0)
+        return [];
+    const entities = ranked.filter((c) => c.signature.startsWith("entity:"));
+    if (entities.length === 0)
+        return ranked.slice(0, max); // tags-only → top-N (capClusters parity)
+    const tags = ranked.filter((c) => !c.signature.startsWith("entity:"));
+    // Reserve up to RESERVED_TAG_SLOTS for tags, but never below one slot for the
+    // leading entities when the budget allows (so a small `maxClustersPerRun` does
+    // not silently invert the entity preference).
+    const reservedForTags = Math.min(tags.length, RESERVED_TAG_SLOTS, Math.max(0, max - 1));
+    const entityTake = Math.min(entities.length, max - reservedForTags);
+    const tagTake = Math.min(tags.length, max - entityTake); // tags take their reserve + any slot entities left
+    // Prefer tight tags (<= soft cap) over broad mega-buckets for the reserve.
+    const reserveTags = [...tags]
+        .sort((a, b) => {
+        const aOver = a.members.length > TAG_RESERVE_SOFT_CAP ? 1 : 0;
+        const bOver = b.members.length > TAG_RESERVE_SOFT_CAP ? 1 : 0;
+        return aOver - bOver || b.members.length - a.members.length || a.signature.localeCompare(b.signature);
+    })
+        .slice(0, tagTake);
+    return [...entities.slice(0, entityTake), ...reserveTags];
+}
 // ── Prompt + ref derivation ───────────────────────────────────────────────────
 /** Read a memory body (frontmatter stripped) for the cluster prompt. */
 function readBody(entry) {
@@ -408,8 +574,9 @@ export async function akmRecombine(opts) {
         ...(entityByEntryId ? { entityByEntryId } : {}),
         ...(opts.maxClusterSize != null ? { maxClusterSize: opts.maxClusterSize } : {}),
         ...(opts.excludeTags ? { excludeTags: opts.excludeTags } : {}),
+        ...(opts.excludeEntities ? { excludeEntities: opts.excludeEntities } : {}),
     });
-    const clusters = capClusters(rankedClusters, maxClustersPerRun);
+    const clusters = selectClustersForRun(rankedClusters, maxClustersPerRun);
     let clustersFormed = 0;
     let proposalsEmitted = 0;
     let lessonsPromoted = 0;

package/dist/core/config/config-schema.js

@@ -316,9 +316,13 @@ export const ImproveProcessConfigSchema = z
     // (generic project-wide tags). Default UNSET/[]. Only meaningful on
     // `recombine`.
     excludeTags: z.array(z.string().min(1)).optional(),
+    // #632 — recombine process: entity_norm values that must never form an
+    // entity cluster (user counterpart to the built-in generic-entity filter).
+    // Default UNSET/[]. Only meaningful on `recombine`.
+    excludeEntities: z.array(z.string().min(1)).optional(),
     // #609 — recombine process: relatedness signal used to form clusters
     // (tags | graph | both). Clustering is by relatedness, never embedding
-    // similarity. Default "tags". Only meaningful on `recombine`.
+    // similarity. Default "both" (#632). Only meaningful on `recombine`.
     relatednessSource: z.enum(["tags", "graph", "both"]).optional(),
     // #609 — recombine process: consecutive re-inductions required before a
     // hypothesis is promoted to a lesson. Default 2. Only meaningful on

package/dist/scripts/migrate-storage.js

@@ -16083,6 +16083,7 @@ var init_config_schema = __esm(() => {
     maxClustersPerRun: positiveInt.optional(),
     maxClusterSize: positiveInt.optional(),
     excludeTags: exports_external.array(exports_external.string().min(1)).optional(),
+    excludeEntities: exports_external.array(exports_external.string().min(1)).optional(),
     relatednessSource: exports_external.enum(["tags", "graph", "both"]).optional(),
     confirmThreshold: exports_external.number().int().min(1).optional(),
     minRecurrence: exports_external.number().int().min(2).optional(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "akm-cli",
-  "version": "0.9.0-beta.42",
+  "version": "0.9.0-beta.44",
   "type": "module",
   "description": "akm (Agent Knowledge Management) — A package manager for AI agent skills, commands, tools, and knowledge. Works with Claude Code, OpenCode, Cursor, and any AI coding assistant.",
   "keywords": [