akm-cli 0.9.30 → 0.9.32
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +40 -0
- package/README.md +10 -10
- package/ROADMAP.md +112 -0
- package/dist/commands/feedback-cli.js +21 -13
- package/dist/commands/improve/improve-cli.js +33 -12
- package/dist/core/errors.js +1 -0
- package/dist/core/file-lock.js +10 -1
- package/dist/indexer/usage/usage-events.js +6 -2
- package/dist/llm/client.js +33 -3
- package/dist/scripts/akm-migrate-node.js +6 -1
- package/dist/scripts/akm-migrate.js +6 -1
- package/docs/README.md +42 -41
- package/docs/agents/README.md +15 -0
- package/docs/agents/agent-install.md +14 -0
- package/docs/architecture/README.md +67 -0
- package/docs/architecture/adapters.md +272 -0
- package/docs/architecture/akm-architecture-decision-history.md +2055 -0
- package/docs/architecture/akm-core-principles.md +126 -0
- package/docs/architecture/architecture.md +579 -0
- package/docs/architecture/comparisons/claude-code-vs-akm-workflows-full.md +550 -0
- package/docs/architecture/decisions/0001-no-interpolation-attached-structured-context.md +72 -0
- package/docs/architecture/decisions/0002-unit-reuse-and-input-hash-scope.md +142 -0
- package/docs/architecture/decisions/0003-child-env-allowlist-and-provenance.md +189 -0
- package/docs/architecture/decisions/0004-task-input-contract-and-flag-coercion.md +97 -0
- package/docs/architecture/decisions/0005-task-result-vocabulary-and-legacy-read-mapping.md +108 -0
- package/docs/architecture/decisions/0006-task-source-version-routing.md +124 -0
- package/docs/architecture/decisions/0007-workflow-composition-bounds.md +83 -0
- package/docs/architecture/decisions/0008-task-binding-normalization.md +88 -0
- package/docs/architecture/decisions/0009-child-run-publication-column-parity.md +80 -0
- package/docs/architecture/decisions/0010-driver-protocol-cut.md +36 -0
- package/docs/architecture/decisions/0011-engine-run-loop-invariants.md +125 -0
- package/docs/architecture/decisions/README.md +62 -0
- package/docs/architecture/improvement.md +440 -0
- package/docs/architecture/internals/classification.md +154 -0
- package/docs/architecture/internals/fresh-host-rebuild-runbook.md +40 -0
- package/docs/architecture/internals/functional-contract-patterns.md +340 -0
- package/docs/architecture/internals/health-advisories.md +110 -0
- package/docs/architecture/internals/improve-workflow.md +713 -0
- package/docs/architecture/internals/indexing.md +498 -0
- package/docs/architecture/internals/registry-network-boundary.md +57 -0
- package/docs/architecture/internals/search.md +249 -0
- package/docs/architecture/internals/storage-locations.md +943 -0
- package/docs/architecture/persisted-data-compat.md +59 -0
- package/docs/architecture/reviews/env-secret-access.md +319 -0
- package/docs/architecture/runtime-boundary-design.md +153 -0
- package/docs/architecture/specs/0.9.0-close-out-plan.md +361 -0
- package/docs/architecture/specs/0.9.0-decisions.md +528 -0
- package/docs/architecture/specs/0.9.0-docs-code-drift-register.md +745 -0
- package/docs/architecture/specs/0.9.0-open-items-register.md +135 -0
- package/docs/architecture/specs/0.9.0-public-api-issue-backlog.md +740 -0
- package/docs/architecture/specs/0.9.0-release-surface-review.md +636 -0
- package/docs/architecture/specs/agent-command-engine-model-design.md +513 -0
- package/docs/architecture/specs/akm-0.9.0-bundle-adapter-spec.md +501 -0
- package/docs/architecture/specs/akm-0.9.0-ref-grammar-decision.md +291 -0
- package/docs/architecture/specs/akm-format-neutral-bundle-workspace-spec.md +2059 -0
- package/docs/architecture/specs/di-seams-plan.md +539 -0
- package/docs/architecture/specs/driver-protocol-keep-or-cut.md +275 -0
- package/docs/architecture/specs/fact-asset-type.md +142 -0
- package/docs/architecture/specs/improve-collapse-churn-detector-design.md +634 -0
- package/docs/architecture/specs/okf-support.md +148 -0
- package/docs/architecture/specs/ref.md +329 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/README.md +72 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/findings-consolidated.md +152 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/library-eval-alternatives.md +352 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/library-eval-bunqueue.md +300 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/library-eval-openworkflow.md +402 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/opus-review-1.md +758 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/opus-review-2.md +645 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/opus-review-3.md +602 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r1-adversarial.md +27 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r1-architecture.md +27 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r1-coverage.md +74 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r1-security.md +15 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r2-adversarial.md +132 -0
- package/docs/architecture/specs/reviews/task-workflow-unification/panel-r2-verification.md +147 -0
- package/docs/architecture/specs/stash-conventions-code-spec.md +275 -0
- package/docs/architecture/specs/stash-organization-conventions.md +377 -0
- package/docs/architecture/specs/task-workflow-format-unification.md +721 -0
- package/docs/architecture/specs/workflow-engine-buy-vs-build.md +231 -0
- package/docs/architecture/specs/workflow-format-unification.md +437 -0
- package/docs/architecture/testing/manual-testing-checklist.md +3420 -0
- package/docs/architecture/testing/okf-v0.2-conformance-runbook.md +924 -0
- package/docs/architecture/testing/task-workflow-manual-tests.md +1817 -0
- package/docs/architecture/testing/testing-workflow.md +446 -0
- package/docs/architecture/workflow-engine.md +274 -0
- package/docs/guides/README.md +33 -0
- package/docs/guides/author-bundles.md +310 -0
- package/docs/guides/author-workflows.md +520 -0
- package/docs/guides/bundles.md +321 -0
- package/docs/guides/capture-knowledge.md +136 -0
- package/docs/guides/claude-code-vs-akm-workflows.md +30 -0
- package/docs/guides/concepts.md +93 -0
- package/docs/guides/discover-and-load.md +158 -0
- package/docs/guides/getting-started.md +240 -0
- package/docs/guides/improve-the-library.md +246 -0
- package/docs/guides/knowledge-management.md +18 -0
- package/docs/guides/recipes/headless-install.md +97 -0
- package/docs/guides/recipes/website-source.md +28 -0
- package/docs/guides/run-workflows.md +279 -0
- package/docs/guides/scheduling.md +123 -0
- package/docs/guides/use-with-any-agent.md +129 -0
- package/docs/guides/wikis.md +81 -0
- package/docs/maintainers/README.md +19 -0
- package/docs/maintainers/curate-workmap.md +336 -0
- package/docs/maintainers/eval.md +3 -0
- package/docs/maintainers/local-development.md +108 -0
- package/docs/maintainers/release-checklist.md +103 -0
- package/docs/migration/README.md +2 -2
- package/docs/migration/release-notes/0.0.13.md +1 -1
- package/docs/migration/release-notes/0.1.0.md +1 -1
- package/docs/migration/release-notes/0.2.0.md +1 -1
- package/docs/migration/release-notes/0.3.0.md +1 -1
- package/docs/migration/release-notes/0.5.0.md +1 -1
- package/docs/migration/release-notes/0.6.0.md +1 -1
- package/docs/migration/release-notes/0.7.0.md +1 -1
- package/docs/migration/release-notes/0.7.3.md +2 -2
- package/docs/migration/release-notes/0.7.4.md +1 -1
- package/docs/migration/release-notes/0.7.5.md +1 -1
- package/docs/migration/release-notes/0.8.0.md +1 -1
- package/docs/migration/release-notes/0.9.0.md +1 -1
- package/docs/migration/release-notes/0.9.14.md +1 -1
- package/docs/migration/release-notes/0.9.15.md +1 -1
- package/docs/migration/release-notes/0.9.16.md +1 -1
- package/docs/migration/release-notes/0.9.17.md +1 -1
- package/docs/migration/release-notes/0.9.19.md +1 -1
- package/docs/migration/release-notes/0.9.2.md +1 -1
- package/docs/migration/release-notes/README.md +27 -31
- package/docs/migration/v0.5-to-v0.6.md +759 -0
- package/docs/migration/v0.8-to-v0.9.md +1 -1
- package/docs/plans/0.9.2-agent-command-workflow-plan.md +423 -0
- package/docs/posts/README.md +30 -0
- package/docs/posts/akm-command-tour.md +495 -0
- package/docs/posts/akm-logo-sized.webp +0 -0
- package/docs/posts/belief-aware-memory-12.md +139 -0
- package/docs/posts/config-v2-lessons-16.md +191 -0
- package/docs/posts/improve-loop-autonomous-10.md +225 -0
- package/docs/posts/improve-pipeline-debugging-0803.md +179 -0
- package/docs/posts/intro-part-01.md +76 -0
- package/docs/posts/intro-part-02.md +221 -0
- package/docs/posts/intro-part-03.md +190 -0
- package/docs/posts/intro-part-04.md +221 -0
- package/docs/posts/llm-mode-reflect-13.md +166 -0
- package/docs/posts/openpalm-built-on-akm.md +86 -0
- package/docs/posts/progressive-disclosure-06.md +129 -0
- package/docs/posts/proposal-safety-net-15.md +112 -0
- package/docs/posts/release-0.5.0.md +247 -0
- package/docs/posts/release-0.6.0.md +117 -0
- package/docs/posts/release-0.7.0.md +159 -0
- package/docs/posts/release-0.8.0.md +332 -0
- package/docs/posts/scattered-skills-05.md +100 -0
- package/docs/posts/task-assets-persistent-workflows-11.md +222 -0
- package/docs/posts/team-skills-07.md +198 -0
- package/docs/posts/wiki-agent-knowledge-08.md +223 -0
- package/docs/posts/workflows-vaults-09.md +321 -0
- package/docs/product-surface.md +54 -0
- package/docs/reference/README.md +1 -2
- package/docs/reference/asset-types.md +168 -0
- package/docs/reference/cli.md +5 -6
- package/docs/reference/data-and-telemetry.md +6 -0
- package/docs/reference/env-and-secrets.md +126 -0
- package/docs/reference/memory.md +124 -0
- package/docs/reference/refs.md +156 -0
- package/docs/reference/registry.md +489 -0
- package/docs/reference/website-sources.md +141 -0
- package/package.json +12 -15
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: The Proposal Queue Safety Net
|
|
3
|
+
cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
|
|
4
|
+
series: akm-knowledge
|
|
5
|
+
description: 'akm''s proposal queue separates agent-generated suggestions from your live stash. Here is the full review workflow, the 0.8.0 guardrails that prevent bulk mistakes, and a daily habit that keeps the queue clean.'
|
|
6
|
+
tags:
|
|
7
|
+
- ai
|
|
8
|
+
- agents
|
|
9
|
+
- memory
|
|
10
|
+
- cli
|
|
11
|
+
published: true
|
|
12
|
+
id: 3814548
|
|
13
|
+
date: '2026-06-04T00:32:02Z'
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
> This is a dated article from AKM's publishing archive. For current product behavior, see the
|
|
17
|
+
> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
|
|
18
|
+
|
|
19
|
+
This is part fifteen in a series about managing the growing pile of skills, scripts, and context that AI coding agents depend on. [Part ten](https://dev.to/itlackey/the-improvement-loop-how-akm-keeps-your-agent-sharp-2d4d) introduced the improve pipeline and how it generates proposals. [Part twelve](https://dev.to/itlackey/belief-aware-memory-teaching-your-agent-when-not-to-write-4egi) covered belief-aware memory, which feeds directly into the confidence scores covered here.
|
|
20
|
+
|
|
21
|
+
The fundamental problem with agent-generated stash updates is trust. You want to capture what the agent learned — the debugging insight from last Tuesday's session, the architectural pattern it derived from reviewing twenty PRs — without blindly writing unreviewed content into the knowledge base your other agents depend on. One bad promotion and you've contaminated search results with a hallucinated fact that will keep showing up until someone notices.
|
|
22
|
+
|
|
23
|
+
akm's proposal queue is the answer to that problem. Introduced in 0.7.0 and extended in 0.8.0, it separates generation from promotion. Every agent-driven change writes to a durable queue first. Nothing reaches your live stash until you explicitly accept it. The queue is the safety net.
|
|
24
|
+
|
|
25
|
+
## How the Queue Works
|
|
26
|
+
|
|
27
|
+
When `akm improve` or `akm proposal new` runs, the output goes to the proposal queue — not to your stash. Proposals live outside the asset tree. They never appear in `akm search` results and never get indexed alongside your real assets. The `quality: "proposed"` marker ensures this at the database level: proposed assets are excluded from default search and only surface through the `akm proposal *` commands or an explicit `--include-proposed` flag.
|
|
28
|
+
|
|
29
|
+
This means an agent can generate dozens of proposals in a single `akm improve` run and none of them affect your live stash until you decide they should. Multiple proposals for the same ref coexist without filesystem collisions. You can review them at your own pace, reject the bad ones, and accept the rest in whatever order makes sense.
|
|
30
|
+
|
|
31
|
+
The complete review workflow:
|
|
32
|
+
|
|
33
|
+
```sh
|
|
34
|
+
akm proposal list # see what's pending
|
|
35
|
+
akm proposal show <id> # render the full proposal content
|
|
36
|
+
akm proposal diff <id> # diff vs. the live version of that ref
|
|
37
|
+
akm proposal accept <id> # validate, then promote to stash
|
|
38
|
+
akm proposal reject <id> --reason "…" # archive with a reason
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
`akm proposal accept` does not just write the file. It runs full validation and routes the write through the same `writeAssetToSource()` path used by `akm remember` and `akm import`. There is no bypass path. A proposal that fails validation does not get promoted.
|
|
42
|
+
|
|
43
|
+
## The 0.8.0 Additions
|
|
44
|
+
|
|
45
|
+
0.8.0 reorganized the proposal commands under the `akm proposal` subcommand (the old flat verbs — `akm proposals`, `akm accept`, `akm reject`, etc. — still work as deprecated aliases until 0.9.0) and added three features that change how you interact with the queue at scale: confidence scores, expiration, and per-proposal revert.
|
|
46
|
+
|
|
47
|
+
**Confidence scores.** Each proposal now carries an optional `confidence` field (a value from 0 to 1) set by the pipeline that generated it. `akm proposal show <id>` includes this field in its JSON output. A high-confidence proposal is one the pipeline assessed as a strong, well-supported improvement. A low-confidence one is speculative or weakly supported. The score is not a gate — you still decide — but it gives you signal for triage. When you have thirty proposals and limited review time, work high-confidence proposals first. (The belief model that drives these scores is covered in [Belief-Aware Memory](https://dev.to/itlackey/belief-aware-memory-teaching-your-agent-when-not-to-write-4egi).)
|
|
48
|
+
|
|
49
|
+
**Expiration.** Proposals expire after a configurable number of days. Set `improve.archiveRetentionDays` in your akm config to control the window (default: 30 days). Stale proposals that you never got around to reviewing are automatically archived rather than accumulating indefinitely. Anything that mattered enough to act on should have been reviewed before it aged out; the archive preserves the full audit trail if you need to look back.
|
|
50
|
+
|
|
51
|
+
**Per-proposal revert.** After you accept a proposal, `akm proposal revert <id>` restores the backup of the previous version. This is not a bulk operation and it is not reversible in batch. You revert one proposal at a time, by ID:
|
|
52
|
+
|
|
53
|
+
```sh
|
|
54
|
+
akm proposal revert <id> # restore the backup for a specific accepted proposal
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
The no-batch-revert constraint is intentional. Bulk accept without bulk revert is the guardrail that forces deliberate review. If you accept fifty proposals in a single command and three of them are bad, you revert those three individually. The discipline is the point — if you were going to bulk-revert, it means you bulk-accepted without reviewing, and the queue exists precisely to prevent that pattern.
|
|
58
|
+
|
|
59
|
+
## Bulk Accept Guardrails
|
|
60
|
+
|
|
61
|
+
For cases where you want to process more than one proposal at a time without bypassing judgment entirely, 0.8.0 extended `akm proposal accept` with generator-scoped batch flags.
|
|
62
|
+
|
|
63
|
+
**`akm proposal accept`** supports generator-scoped bulk operations. When you want to accept all pending proposals from a specific generator, pass `--generator` without a positional id. Bulk accept requires `-y`/`--yes`:
|
|
64
|
+
|
|
65
|
+
```sh
|
|
66
|
+
akm proposal accept --generator reflect --yes # accept all reflect proposals
|
|
67
|
+
akm proposal accept --generator distill --yes # accept all distill proposals
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
The `--yes` flag removes the interactive confirmation prompt required in non-interactive shells. Use it only after you have already reviewed the queue via `akm proposal list` and `akm proposal diff`. Bulk accept without prior review is exactly the pattern the queue exists to prevent.
|
|
71
|
+
|
|
72
|
+
## Auto-Accept for Trusted Sources
|
|
73
|
+
|
|
74
|
+
If you have a source you fully trust — a well-constrained task asset running against a curated input set, or a distill job that only ever touches a specific category — you can set a high `autoAccept` threshold in that improve profile. Proposals whose confidence meets or exceeds the threshold are promoted directly to the stash without manual review.
|
|
75
|
+
|
|
76
|
+
This is off by default and should stay off for most sources. The value of the queue is exactly that it sits between agent output and your live stash. Auto-accept makes sense only when the source is trusted, the scope is narrow, and you are comfortable with the output quality from experience rather than assumption.
|
|
77
|
+
|
|
78
|
+
## A Daily Review Habit
|
|
79
|
+
|
|
80
|
+
The proposal queue only helps if you actually review it. Left unattended, it either accumulates into a backlog that's too large to meaningfully triage, or proposals expire before you get to them. A brief daily review pass keeps it manageable.
|
|
81
|
+
|
|
82
|
+
The workflow that works:
|
|
83
|
+
|
|
84
|
+
```sh
|
|
85
|
+
# Start with the full pending list
|
|
86
|
+
akm proposal list
|
|
87
|
+
|
|
88
|
+
# For each proposal worth reading, diff it against the live ref
|
|
89
|
+
akm proposal diff <id>
|
|
90
|
+
|
|
91
|
+
# Accept the ones that look right
|
|
92
|
+
akm proposal accept <id>
|
|
93
|
+
|
|
94
|
+
# Reject the ones that don't, with a reason you'll understand later
|
|
95
|
+
akm proposal reject <id> --reason "hallucinated — no source for this claim"
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
The diff is the most useful step. `akm proposal diff <id>` shows you the delta between the proposal and whatever currently exists for that ref in your live stash. A proposal that adds accurate new context to a ref you already maintain is easy to accept. A proposal that rewrites a ref you know well with confident-sounding but unverifiable claims is easy to reject. The diff makes the difference visible.
|
|
99
|
+
|
|
100
|
+
If the queue is empty, the daily review takes thirty seconds. If `akm improve` ran overnight and produced twenty proposals, budget ten minutes. The point is not to process every proposal — it is to stay close enough to the queue that nothing accumulates into a block of work large enough to skip.
|
|
101
|
+
|
|
102
|
+
For teams running `akm improve` on a schedule, the confidence scores make triage faster. High-confidence proposals need a quick diff and a decision. Low-confidence proposals need closer reading or an outright reject. Over time, the pattern of what the pipeline marks as high-confidence and what actually turns out to be good teaches you where to focus attention.
|
|
103
|
+
|
|
104
|
+
## The Shape of Safe Agent Memory
|
|
105
|
+
|
|
106
|
+
The proposal queue is not a bureaucratic checkpoint. It is the mechanism that makes it safe to run `akm improve` continuously, trust agent-driven reflection passes, and still maintain a knowledge base where you know what is in it and why.
|
|
107
|
+
|
|
108
|
+
Without the queue, you are choosing between running the improve pipeline (accepting everything it produces) or not running it (getting nothing it produces). The queue is the third option: run it continuously, review the output deliberately, promote what earned it. The 0.8.0 guardrails — confidence scores, expiration, per-proposal revert, and generator-scoped bulk accept — are the tools that make that third option practical at the scale continuous operation produces.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
The proposal queue is available as of akm 0.7.0. The 0.8.0 additions — confidence scores, expiration, `akm proposal revert`, and generator-scoped bulk accept — require 0.8.0 or later. Full reference at [CLI reference](../reference/cli.md#proposal) and the [configuration reference](../reference/configuration.md).
|
|
@@ -0,0 +1,247 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: 'akm 0.5.0: Wikis, Workflows, Vaults, and a Writable Stash'
|
|
3
|
+
cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
|
|
4
|
+
series: akm-releases
|
|
5
|
+
description: 'akm 0.5.0 ships multi-wiki support, workflow and vault asset types, writable git stash sync, and a one-off --trust install bypass.'
|
|
6
|
+
tags:
|
|
7
|
+
- ai
|
|
8
|
+
- agents
|
|
9
|
+
- cli
|
|
10
|
+
- release
|
|
11
|
+
published: true
|
|
12
|
+
date: '2026-04-24T05:18:44Z'
|
|
13
|
+
id: 3539588
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
> This is a dated article from AKM's publishing archive. For current product behavior, see the
|
|
17
|
+
> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
|
|
18
|
+
|
|
19
|
+
akm 0.5.0 is out. This release adds three new asset types — wikis, workflows, and vaults are now first-class citizens — plus writable git stash support so your stash can sync back to a remote. It also upgrades the self-update path to cover npm, bun, pnpm, and binary installs, and ships a new `akm help migrate` command for release-to-release guidance. There is one breaking change for anyone who was using the single-wiki LLM POC from 0.4.x.
|
|
20
|
+
|
|
21
|
+
## TL;DR
|
|
22
|
+
|
|
23
|
+
- `akm wiki create|register|list|show|remove|pages|search|stash|lint|ingest` — multi-wiki support, no LLM required
|
|
24
|
+
- `akm workflow template|create|start|next|complete|status|list|resume` — multi-step agent procedures in the stash
|
|
25
|
+
- `akm vault list|show|create|set|unset|load` — `.env`-backed secrets that never appear in structured output
|
|
26
|
+
- `akm add <source> --writable` + `akm save` — push your stash changes back to a remote git repo
|
|
27
|
+
- `akm add <source> --trust` — bypass the install audit for a single install
|
|
28
|
+
- `akm add --type wiki --name <name> <source>` / `akm wiki register` — register an existing directory or repo as a first-class wiki
|
|
29
|
+
- `akm upgrade` now covers npm, bun, pnpm, and standalone-binary installs
|
|
30
|
+
- `akm help migrate <version>` prints release notes and migration guidance for any shipped release
|
|
31
|
+
- **Breaking**: the single-wiki LLM POC is removed; migrate to `akm wiki …`
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## Multi-wiki support
|
|
36
|
+
|
|
37
|
+
The biggest addition in 0.5.0 is a proper wiki asset type. A wiki is a structured knowledge base living at `<stashDir>/wikis/<name>/` with a defined layout: `schema.md` describes what goes in it, `index.md` is auto-generated by `akm index`, `log.md` tracks change history, `raw/` holds unprocessed source material, and the rest are agent-authored pages.
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
# Create a new wiki
|
|
41
|
+
akm wiki create architecture # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
42
|
+
|
|
43
|
+
# List all wikis
|
|
44
|
+
akm wiki list # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
45
|
+
|
|
46
|
+
# See what pages a wiki has
|
|
47
|
+
akm wiki pages architecture # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
48
|
+
|
|
49
|
+
# Search within a wiki
|
|
50
|
+
akm wiki search architecture "deployment" # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
51
|
+
|
|
52
|
+
# Lint a wiki for structural problems
|
|
53
|
+
akm wiki lint architecture # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
54
|
+
|
|
55
|
+
# Ingest raw content into raw/
|
|
56
|
+
akm wiki stash architecture ./notes/adr-001.md # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
57
|
+
|
|
58
|
+
# Print the ingest workflow for the wiki
|
|
59
|
+
akm wiki ingest architecture # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
Wiki pages are indexed by `akm index` and show up in stash-wide `akm search`, so you do not need to remember which wiki a page lives in. Raw sources under `raw/` plus the wiki root infrastructure files `schema.md`, `index.md`, and `log.md` are intentionally excluded from indexing and search results. Running `akm index` also regenerates each wiki's `index.md` as a side effect.
|
|
63
|
+
|
|
64
|
+
The design principle is **akm surfaces, the agent writes**. akm makes no LLM calls. It owns only the operations where correctness is structural and deterministic: lifecycle management, raw-slug uniqueness, lint checks, index regeneration. The agent owns page content. This keeps the CLI fast and predictable — a wiki command always completes in milliseconds, and you can run it in any environment without model configuration.
|
|
65
|
+
|
|
66
|
+
The 10-verb surface (`create`, `register`, `list`, `show`, `remove`, `pages`, `search`, `stash`, `lint`, `ingest`) covers the full lifecycle from creation to indexing to removal.
|
|
67
|
+
|
|
68
|
+
If you already have a wiki-shaped directory or repo you want to adopt without copying it, use `akm wiki register`:
|
|
69
|
+
|
|
70
|
+
```sh
|
|
71
|
+
# Register a local directory as a first-class wiki
|
|
72
|
+
akm wiki register notes ~/team/notes # doclint:ignore (historical — akm 0.5.0 release announcement; `wiki` family removed in 0.9.0)
|
|
73
|
+
|
|
74
|
+
# Or via the unified add command
|
|
75
|
+
akm add --type wiki --name notes ~/team/notes # doclint:ignore (historical — akm 0.5.0 release announcement; `--type` removed from `add` in the 0.9.0 bundle-adapter refactor)
|
|
76
|
+
|
|
77
|
+
# Registered external wikis show up in both `akm list` and `akm wiki list`
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Registration refreshes source state and wiki search hits immediately, and the indexer normalizes external wiki refs on subsequent runs.
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
## Workflow asset type
|
|
85
|
+
|
|
86
|
+
Workflows are multi-step procedures stored in the stash. An agent running a complex process — a release checklist, an onboarding sequence, a debugging runbook — can use `akm workflow next` to step through it deterministically rather than relying on its context window to track state.
|
|
87
|
+
|
|
88
|
+
```sh
|
|
89
|
+
# Author a workflow
|
|
90
|
+
akm workflow create release-checklist
|
|
91
|
+
|
|
92
|
+
# Start an instance
|
|
93
|
+
akm workflow start workflow:release-checklist # doclint:ignore (historical 0.5.0 workflow lifecycle removed in 0.9)
|
|
94
|
+
|
|
95
|
+
# Advance to the next step
|
|
96
|
+
akm workflow next workflow:release-checklist # doclint:ignore (historical 0.5.0 workflow lifecycle removed in 0.9)
|
|
97
|
+
|
|
98
|
+
# Check where you are
|
|
99
|
+
akm workflow status workflow:release-checklist
|
|
100
|
+
|
|
101
|
+
# Mark a specific step done (defaults to --state completed)
|
|
102
|
+
akm workflow complete <run-id> --step validate --notes "Inputs verified" # doclint:ignore (historical 0.5.0 workflow lifecycle removed in 0.9)
|
|
103
|
+
|
|
104
|
+
# List all workflow runs
|
|
105
|
+
akm workflow list
|
|
106
|
+
|
|
107
|
+
# Print a starter workflow you can adapt
|
|
108
|
+
akm workflow template # doclint:ignore (historical — akm 0.5.0 release announcement; `template` folded into `workflow create --print` in the 0.9.0 CLI overhaul)
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
Workflows live in the stash like any other asset, so `akm search workflow:…` finds them and `akm show workflow:release-checklist` renders the current step. They can be shared in a stash and versioned in a git stash.
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## Vault asset type
|
|
116
|
+
|
|
117
|
+
Vaults store secrets and environment configuration. Each vault is a `.env` file in the stash. The key constraint: vault values never appear in structured output. `akm show vault:<name>` and `akm vault list` display key names and metadata, but not the values themselves.
|
|
118
|
+
|
|
119
|
+
```sh
|
|
120
|
+
# List vaults
|
|
121
|
+
akm vault list # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
122
|
+
|
|
123
|
+
# Show keys in a vault (no values)
|
|
124
|
+
akm show vault:prod-secrets
|
|
125
|
+
|
|
126
|
+
# Create a new empty vault
|
|
127
|
+
akm vault create prod-secrets # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
128
|
+
|
|
129
|
+
# Set a key (three-positional form or combined KEY=VALUE form)
|
|
130
|
+
akm vault set vault:prod-secrets API_KEY abc123 # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
131
|
+
akm vault set vault:prod-secrets API_KEY=abc123 --comment "Rotate every 90 days" # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
132
|
+
|
|
133
|
+
# Remove a key
|
|
134
|
+
akm vault unset vault:prod-secrets API_KEY # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
135
|
+
|
|
136
|
+
# Print the vault file path for current-shell loading
|
|
137
|
+
source "$(akm vault path vault:prod-secrets)"
|
|
138
|
+
|
|
139
|
+
# Run one command with the vault injected
|
|
140
|
+
akm vault run vault:prod-secrets -- env # doclint:ignore (historical — akm 0.5.0 release announcement; `vault` type removed in 0.9.0, see `env`/`secret`)
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
`akm vault path` is the current-shell loading path and `akm vault run` is the one-shot command execution path. Values never appear in structured output; `vault run` passes them directly to the child process environment.
|
|
144
|
+
|
|
145
|
+
This is a deliberate tradeoff: vaults are not a full secrets manager. They are a thin, auditable layer that keeps your `.env` files alongside your other agent assets and prevents accidental leakage through `akm show` or `akm search` results.
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## Writable git stash and `akm save`
|
|
150
|
+
|
|
151
|
+
Until now, git-backed stashes were read-only: `akm add github:owner/repo` would clone the repo, but you could not push changes back. 0.5.0 changes that.
|
|
152
|
+
|
|
153
|
+
```sh
|
|
154
|
+
# Clone a git stash and opt it into push-on-save
|
|
155
|
+
akm add github:your-org/your-stash --writable # doclint:ignore (historical — pre-0.9.0 command spelling)
|
|
156
|
+
|
|
157
|
+
# Make some changes — add a skill, author a wiki page, record a memory
|
|
158
|
+
akm remember "Production DB is read-only on Sundays"
|
|
159
|
+
|
|
160
|
+
# Commit and push
|
|
161
|
+
akm save -m "add production DB note" # doclint:ignore (historical — akm 0.5.0 release announcement; `save` renamed `sync` in 0.9.0, `-m` survives as `sync`'s own alias)
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
If the stash has a remote configured and `--writable` was used on install, `akm save` runs `git commit` and `git push`. Without `--writable` (or without a remote), it commits locally only.
|
|
165
|
+
|
|
166
|
+
The default stash is now auto-initialized as a git repo on `akm setup`, so `akm save` works out of the box even before you wire up a remote.
|
|
167
|
+
|
|
168
|
+
The git stash provider also switches from HTTP tarball download to `git clone`, which means you get proper git history and the ability to `git pull` manually if you prefer.
|
|
169
|
+
|
|
170
|
+
---
|
|
171
|
+
|
|
172
|
+
## `--trust` flag for installs
|
|
173
|
+
|
|
174
|
+
akm 0.4.0 added a pre-install audit that scans stash contents for dangerous patterns. By default, installs from unrecognized sources require confirmation. For sources you know and trust, you can skip the audit entirely:
|
|
175
|
+
|
|
176
|
+
```sh
|
|
177
|
+
akm add github:your-org/internal-stash --trust # doclint:ignore (historical — akm 0.5.0 release announcement; `--trust` no longer a flag on current `add`)
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
`--trust` is a one-off bypass — it does not add the source to any persistent allowlist. Use it when you control the source and do not want to step through the audit prompt in a non-interactive context (a CI script, an automated agent workflow, a container build).
|
|
181
|
+
|
|
182
|
+
When a blocked install error occurs, the error message includes a `hint` field referencing `--trust` as a remediation option.
|
|
183
|
+
|
|
184
|
+
---
|
|
185
|
+
|
|
186
|
+
## Breaking change: single-wiki LLM POC removed
|
|
187
|
+
|
|
188
|
+
If you were using the wiki functionality introduced in 0.4.1, you will need to migrate. The following have been removed:
|
|
189
|
+
|
|
190
|
+
- `akm lint` command
|
|
191
|
+
- `akm import --llm` and `akm import --dry-run` flags
|
|
192
|
+
- `knowledge.pageKinds` config key
|
|
193
|
+
- The `ingestKnowledgeSource` and `lintKnowledge` LLM prompts
|
|
194
|
+
|
|
195
|
+
**Migration path:**
|
|
196
|
+
|
|
197
|
+
1. Create a wiki for your content: `akm wiki create <name>`
|
|
198
|
+
2. Move raw source files into `wikis/<name>/raw/`: `akm wiki stash <name> <file>`
|
|
199
|
+
3. Have your agent author wiki pages from the raw content
|
|
200
|
+
4. Run `akm index` to regenerate the wiki index
|
|
201
|
+
|
|
202
|
+
The new surface is more capable — 10 verbs vs the old 2, proper multi-wiki support, structural lint, and page search — and it does not require an LLM to be configured for any of the CLI operations.
|
|
203
|
+
|
|
204
|
+
---
|
|
205
|
+
|
|
206
|
+
## Broader `akm upgrade` coverage
|
|
207
|
+
|
|
208
|
+
`akm upgrade` used to assume a standalone-binary install. 0.5.0 detects how akm was installed (npm, bun, pnpm, or binary) and runs the right self-update path for each. The same command now works whether you bootstrapped from the install script or from a package manager, and the internal runtime-asset coverage was expanded so newly shipped asset types stay up to date after an upgrade.
|
|
209
|
+
|
|
210
|
+
```sh
|
|
211
|
+
akm upgrade # Works for binary, npm, bun, and pnpm installs
|
|
212
|
+
akm upgrade --check # Report whether an update is available, without installing
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
217
|
+
## `akm help migrate <version>` — release notes at the CLI
|
|
218
|
+
|
|
219
|
+
Release notes belong where you're actually working. `akm help migrate` prints the relevant CHANGELOG section plus embedded migration guidance for a given version, so you can review what changed (and what to do about it) without leaving the terminal.
|
|
220
|
+
|
|
221
|
+
```sh
|
|
222
|
+
akm help migrate 0.5.0 # or v0.5.0
|
|
223
|
+
akm help migrate latest # resolve against the most recent CHANGELOG entry
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
It favors the bundled CHANGELOG section when it exists and falls back to an embedded summary and a link to the full changelog otherwise.
|
|
227
|
+
|
|
228
|
+
---
|
|
229
|
+
|
|
230
|
+
## Upgrade
|
|
231
|
+
|
|
232
|
+
```sh
|
|
233
|
+
akm upgrade
|
|
234
|
+
```
|
|
235
|
+
|
|
236
|
+
Or reinstall from scratch:
|
|
237
|
+
|
|
238
|
+
```sh
|
|
239
|
+
curl -fsSL https://raw.githubusercontent.com/itlackey/akm/main/install.sh | bash
|
|
240
|
+
```
|
|
241
|
+
|
|
242
|
+
Full changelog at [CHANGELOG.md](https://github.com/itlackey/akm/blob/main/.github/CHANGELOG.md).
|
|
243
|
+
|
|
244
|
+
|
|
245
|
+
---
|
|
246
|
+
|
|
247
|
+
> **Note (2026-04-23):** This post has been updated to align with akm 0.6.0 terminology. Earlier wording referred to a *kit* and the *Kit Maker's Guide*; those terms have been renamed to *stash* and *Stash Maker's Guide* throughout. The pre-rename text is preserved in this repository's git history.
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: 'akm 0.6.0: Clean Break to Stash, Quieter CLI, Easier Migration'
|
|
3
|
+
cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
|
|
4
|
+
series: akm-releases
|
|
5
|
+
description: 'akm 0.6.0 simplifies stash terminology, lockfile naming, and wire format before v1.'
|
|
6
|
+
tags:
|
|
7
|
+
- ai
|
|
8
|
+
- agents
|
|
9
|
+
- cli
|
|
10
|
+
- release
|
|
11
|
+
published: true
|
|
12
|
+
id: 3611982
|
|
13
|
+
date: '2026-05-05T02:19:46Z'
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
> This is a dated article from AKM's publishing archive. For current product behavior, see the
|
|
17
|
+
> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
|
|
18
|
+
|
|
19
|
+
akm 0.6.0 is out. This one is deliberately boring: a stabilization release that takes a clean break from pre-v1 terminology so the surface area we carry into v1 is honest. The domain model now has one noun for "a source of content" (stash) and one noun for "a service that helps discover them" (registry). The parallel vocabulary that accreted during earlier experiments — "kit", "source", hand-special-cased provider types — is gone. A handful of additive quality-of-life improvements ship alongside, but the headline story is fewer concepts, not more.
|
|
20
|
+
|
|
21
|
+
If you are on 0.5.x, read [the v0.5 → v0.6 migration guide](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md) before upgrading. Most projects will work without edits thanks to automatic on-disk migrations; a small number of config fields and CLI flags need explicit updates.
|
|
22
|
+
|
|
23
|
+
## TL;DR
|
|
24
|
+
|
|
25
|
+
- **One domain noun**: `kits` / `sources` → `stash` everywhere. Wire format, config, CLI help, and docs all use the same word.
|
|
26
|
+
- **Schema v3** for the registry index: `stashes[]` replaces `kits[]`. Pre-0.6.0 indexes are no longer read.
|
|
27
|
+
- **`akm.lock`** replaces `stash.lock`; auto-copied on first run, no action needed.
|
|
28
|
+
- **`stashInheritance: "merge" | "replace"`** replaces the boolean `disableGlobalStashes`.
|
|
29
|
+
- **`primary: true`** on a stash entry replaces the top-level `stashDir` field.
|
|
30
|
+
- **`--detail=agent`** is the preferred spelling; `--for-agent` stays as a deprecated alias.
|
|
31
|
+
- **`akm enable context-hub` / `akm disable context-hub`** are gone — add context-hub as a regular git stash.
|
|
32
|
+
- **Discovery**: registry indexes only packages/repos tagged `akm-stash`. The pre-0.6.0 `akm-kit` / `agentikit` keywords/topics are not honored as fallbacks.
|
|
33
|
+
|
|
34
|
+
Full details — including before/after code for every item — live in the migration guide.
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## What "clean break" means
|
|
39
|
+
|
|
40
|
+
This is a simplification, not a rebrand. Through the pre-v1 releases, akm accumulated three overlapping nouns for the same concept:
|
|
41
|
+
|
|
42
|
+
- "source" — the config field users saw
|
|
43
|
+
- "kit" — the packaging / publishing story
|
|
44
|
+
- "stash" — the runtime/storage layer
|
|
45
|
+
|
|
46
|
+
Three words for one thing made every doc page ambiguous and every new feature pick a side. 0.6.0 collapses the three into **stash** at every layer — config, wire format, CLI text, docs, error messages. "Agent Kit Manager" stays as the project tagline and `akm-cli` stays as the package name, because those are *product* names, not data-model terms. Everything below the product surface is stash.
|
|
47
|
+
|
|
48
|
+
The registry wire format follows the same logic. Schema v3 drops `kits[]` and parses only `stashes[]`. Pre-v1 is the right time to do this: there is no installed base we need to keep parsing legacy wire formats for, and holding onto `kits[]` just to be polite would trap the v1 contract in historical cruft.
|
|
49
|
+
|
|
50
|
+
## Breaking changes at a glance
|
|
51
|
+
|
|
52
|
+
Each bullet below links to its section in the migration guide, which has the exact before/after code or config diff.
|
|
53
|
+
|
|
54
|
+
- [`stash.lock` → `akm.lock`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#1-stashlock--akmlock) — auto-copied on first run.
|
|
55
|
+
- [`installed[]` → `stashes[]` + `akm.lock`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#2-installed--stashes--akmlock) — config cleanup happens on next write.
|
|
56
|
+
- [`stashDir` → `primary: true`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#3-stashdir--primary-true) — automatic.
|
|
57
|
+
- [`disableGlobalStashes` → `stashInheritance`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#1-replace-disableglobalstashes) — **manual**, one-line config edit.
|
|
58
|
+
- [`--for-agent` → `--detail=agent`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#2-replace---for-agent-with---detailagent) — old flag still works as a deprecated alias for one release cycle.
|
|
59
|
+
- [`akm enable/disable context-hub` removed](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#3-replace-akm-enable-context-hub--akm-disable-context-hub) — add it as a regular git stash.
|
|
60
|
+
- [Wire format `kits[]` → `stashes[]`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#wire-format-change-kits--stashes) — registry publishers must regenerate.
|
|
61
|
+
- [Discovery keyword / topic `akm-kit` → `akm-stash`](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#publisher--kit-maker-changes) — publishers must re-tag.
|
|
62
|
+
|
|
63
|
+
If you consume only the public registry and do not maintain your own, the publisher changes do not apply to you.
|
|
64
|
+
|
|
65
|
+
## What's new (low-key)
|
|
66
|
+
|
|
67
|
+
A few additive improvements rode along with the cleanup.
|
|
68
|
+
|
|
69
|
+
- **`akm workflow validate <ref|path>`** — new subcommand for validating a workflow markdown file or ref; lists every error in one pass (without running a full reindex). A workflow debugging tool to surface issues before they bite at run time.
|
|
70
|
+
- **Memory frontmatter on `akm remember`** — `--tag` (repeatable), `--expires 30d`, `--source <any-string>`, plus opt-in `--auto` (heuristics) and `--enrich` (LLM) for deriving tags from the body. Zero-flag `akm remember "body"` still writes a flat memory, so existing agent scripts are unchanged. Issue [#169](https://github.com/itlackey/akm/issues/169).
|
|
71
|
+
|
|
72
|
+
```sh
|
|
73
|
+
akm remember "VPN required for staging deploys" \
|
|
74
|
+
--tag ops --tag networking --expires 90d --source "skill:deploy"
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
- **Workflow parser accepts intro prose** — you can now put a short advisory paragraph between `# Workflow:` and the first `## Step:` without tripping a validation error. Issue [#158](https://github.com/itlackey/akm/issues/158).
|
|
78
|
+
- **Workflow resume reclassifies blocked steps** — `akm workflow resume <id>` now re-opens the currently-blocked step so you can mark it `completed`, `failed`, or `skipped` after resolving the blocker. Issue [#156](https://github.com/itlackey/akm/issues/156).
|
|
79
|
+
- **Workflow create works in clean stashes** — `akm workflow create <name>` (and `--from <file>`) no longer false-positive on a path escape when any ancestor of the stash is a symlink. Issue [#157](https://github.com/itlackey/akm/issues/157).
|
|
80
|
+
- **Registry search drops empty hit objects** — providers returning partial records no longer surface as `{}` in JSON output; dropped counts appear in `warnings` so the upstream bug stays visible. Issue [#159](https://github.com/itlackey/akm/issues/159).
|
|
81
|
+
- **Isolated sandbox recipe** — [Getting Started](../guides/getting-started.md#isolated-sandbox-workflow) now includes the one-terminal recipe for a throwaway `HOME` + `XDG_*` + `AKM_STASH_DIR` sandbox. Handy for agent testing, CI, and issue reproduction. Issue [#160](https://github.com/itlackey/akm/issues/160).
|
|
82
|
+
|
|
83
|
+
None of these require migration action; they are upgrades-by-default once you install 0.6.0.
|
|
84
|
+
|
|
85
|
+
## Migration
|
|
86
|
+
|
|
87
|
+
Install:
|
|
88
|
+
|
|
89
|
+
```sh
|
|
90
|
+
npm install -g akm-cli@0.6.0
|
|
91
|
+
# or
|
|
92
|
+
bun install -g akm-cli@0.6.0
|
|
93
|
+
# or from an existing install
|
|
94
|
+
akm upgrade
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Read:
|
|
98
|
+
|
|
99
|
+
- [v0.5 → v0.6 migration guide](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md) — every breaking change with before/after code; publisher checklist if you maintain a registry or an npm/GitHub stash.
|
|
100
|
+
|
|
101
|
+
Verify:
|
|
102
|
+
|
|
103
|
+
```sh
|
|
104
|
+
akm info --format text # version 0.6.x, no context-hub provider
|
|
105
|
+
akm config list # stashes[] populated, no installed[]
|
|
106
|
+
akm list # your sources resolve cleanly # doclint:ignore (historical — pre-0.9.0 command spelling)
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
If something looks wrong after upgrade, the guide has a [troubleshooting section](https://github.com/itlackey/akm/blob/main/docs/migration/v0.5-to-v0.6.md#troubleshooting) covering the common pitfalls (stale context-hub entries, v2 registry URLs, empty `stashes[]` after a read-only upgrade path).
|
|
110
|
+
|
|
111
|
+
## What's next
|
|
112
|
+
|
|
113
|
+
0.6.0 is a punctuation mark, not a destination. The next moves are narrower scope and fewer concepts, in that order. Expect the 0.6.x series to pick up whatever friction falls out of this rename; 0.7 starts shaping the contract we intend to freeze at v1.
|
|
114
|
+
|
|
115
|
+
Thank you to everyone who stayed on pre-v1 through the terminology churn. The point of doing this now — while the installed base is small enough to move together — is that we only do it once. The v1 surface begins here.
|
|
116
|
+
|
|
117
|
+
Full changelog at [CHANGELOG.md](https://github.com/itlackey/akm/blob/main/.github/CHANGELOG.md).
|
|
@@ -0,0 +1,159 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: 'akm 0.7.0: Proposal Queue, Reflection Commands, Lessons, and akm-bench'
|
|
3
|
+
cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
|
|
4
|
+
series: akm-releases
|
|
5
|
+
description: 'akm 0.7.0 adds the proposal queue, reflection commands, lessons, and akm-bench.'
|
|
6
|
+
tags:
|
|
7
|
+
- ai
|
|
8
|
+
- agents
|
|
9
|
+
- cli
|
|
10
|
+
- release
|
|
11
|
+
published: true
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
> This is a dated article from AKM's publishing archive. For current product behavior, see the
|
|
15
|
+
> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
|
|
16
|
+
|
|
17
|
+
akm 0.7.0 is out. This is the last pre-1.0 ship in the v1 cycle. The headline features are a durable proposal queue that routes all agent-suggested changes through a single reviewable path, three new CLI surfaces (`reflect`, `propose`, `distill`) that write into that queue, a `lesson` asset type for synthesized knowledge, per-call-site LLM feature gates that are all off by default, and a paired-run benchmarking framework (`akm-bench`) for measuring whether your stash actually improves agent outcomes. A batch of security, UX, and hygiene hardening rounds out the release.
|
|
18
|
+
|
|
19
|
+
If you are on 0.6.x, the v1 migration guide covers the per-surface delta. The upgrade is opt-in — everything new requires explicit configuration or a new command invocation.
|
|
20
|
+
|
|
21
|
+
## TL;DR
|
|
22
|
+
|
|
23
|
+
- **Proposal queue** (`akm proposal list/show/diff/accept/reject`) — all agent-generated changes flow through a durable queue before touching your stash.
|
|
24
|
+
- **`akm reflect`, `akm propose`, `akm distill`** — three new commands that produce proposals without mutating live stash content.
|
|
25
|
+
- **`lesson` asset type** — first-class synthesized knowledge, produced by `akm distill` and promoted via `akm proposal accept`.
|
|
26
|
+
- **`llm.features.*` map** — seven opt-in gates (all `false` by default) for bounded in-tree LLM call sites.
|
|
27
|
+
- **`quality: "proposed"`** — proposed assets are excluded from default search; surface them via `--include-proposed` or `akm proposal *`.
|
|
28
|
+
- **`akm-bench` v1** — paired noakm/akm runs, per-ref attribution, delta reporting.
|
|
29
|
+
- **Security hardening** — git message sanitization, bench env isolation, LLM body redaction, npm tarball host validation.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Proposal queue (`akm proposal *`)
|
|
34
|
+
|
|
35
|
+
The fundamental problem with agent-generated suggestions is trust: you want to capture what the agent learned without blindly writing unreviewed content into your stash. The proposal queue solves this by separating generation from promotion.
|
|
36
|
+
|
|
37
|
+
All proposal-producing commands write to a durable queue that lives outside the asset tree. Unaccepted drafts never appear in search results or get committed. When you're ready to accept a proposal, `akm proposal accept` runs full validation and then routes the write through the same `writeAssetToSource()` path used by `akm remember` and `akm import` — no special handling, no bypass.
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
akm proposal list # list pending proposals
|
|
41
|
+
akm proposal show <id> # render one proposal
|
|
42
|
+
akm proposal diff <id> # diff vs. the live ref
|
|
43
|
+
akm proposal accept <id> # validate, then promote to stash
|
|
44
|
+
akm proposal reject <id> --reason "…" # archive with reason
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
Multiple proposals for the same ref coexist without filesystem collisions. Auto-accept can be enabled per-source via `autoAcceptProposals: true` in your stash config (requires a writable source, defaults off).
|
|
48
|
+
|
|
49
|
+
## Three new commands: `reflect`, `propose`, `distill`
|
|
50
|
+
|
|
51
|
+
These three commands are the primary way to generate proposals.
|
|
52
|
+
|
|
53
|
+
```sh
|
|
54
|
+
akm reflect [ref] [--task ...] # reflect on an asset and propose improvements — doclint:ignore (historical — akm 0.7.0 release announcement; folded into `akm improve` later)
|
|
55
|
+
akm propose <type> <name> --task "…" # generate a new asset as a proposal — doclint:ignore (historical — akm 0.7.0 release announcement; moved to `akm proposal new` in 0.9.0)
|
|
56
|
+
akm distill <ref> # synthesize a lesson from an asset — doclint:ignore (historical — akm 0.7.0 release announcement; folded into `akm improve` later)
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
`reflect` and `propose` shell out to your configured agent CLI and write only to the proposal queue — they never mutate live stash content. `distill` is a bounded in-tree LLM call, gated behind `llm.features.feedback_distillation`, that produces a `lesson`-type proposal from an existing asset.
|
|
60
|
+
|
|
61
|
+
All three emit usage events so you can track which workflows you're actually using.
|
|
62
|
+
|
|
63
|
+
## `lesson` asset type
|
|
64
|
+
|
|
65
|
+
`lesson` is a new first-class asset type designed for synthesized knowledge — the kind your agent derives from experience rather than imports from a source. Lessons are stored under `lessons/<name>.md` in your working stash, parallel to `memories/`. Required frontmatter: `description` and `when_to_use`.
|
|
66
|
+
|
|
67
|
+
The canonical workflow: `akm distill <ref>` produces a lesson proposal → `akm proposal list` shows it → `akm proposal accept <id>` promotes it to your stash. Direct authoring via `akm import` or `akm remember`-style flows is also supported if you want to write lessons manually.
|
|
68
|
+
|
|
69
|
+
## `llm.features.*` — opt-in LLM gates
|
|
70
|
+
|
|
71
|
+
Every bounded in-tree LLM call site is now gated behind exactly one feature flag. All defaults are `false`, so enabling the schema has no effect until you opt in. Seven flags ship in 0.7.0:
|
|
72
|
+
|
|
73
|
+
| Key | What it enables |
|
|
74
|
+
| --- | --- |
|
|
75
|
+
| `curate_rerank` | LLM rerank in `akm curate` |
|
|
76
|
+
| `tag_dedup` | LLM tag dedup during indexer enrichment |
|
|
77
|
+
| `memory_consolidation` | `akm remember --enrich` consolidation |
|
|
78
|
+
| `feedback_distillation` | `akm distill <ref>` |
|
|
79
|
+
| `embedding_fallback_score` | Scorer fallback when embeddings unavailable |
|
|
80
|
+
| `memory_inference` | Indexer split of pending memories into atomic facts |
|
|
81
|
+
| `graph_extraction` | Indexer entity/relation extraction → SQLite graph tables |
|
|
82
|
+
|
|
83
|
+
Turn on what you want:
|
|
84
|
+
|
|
85
|
+
```sh
|
|
86
|
+
akm config set llm.features.feedback_distillation true
|
|
87
|
+
akm config set llm.features.memory_consolidation true
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Every gated call site uses the `tryLlmFeature()` wrapper from `src/llm/feature-gate.ts`, which guarantees: disabled → fallback returned without ever calling the LLM; throw → error swallowed, fallback returned; timeout → 30-second hard limit, fallback returned.
|
|
91
|
+
|
|
92
|
+
## `quality: "proposed"` and `--include-proposed`
|
|
93
|
+
|
|
94
|
+
`SearchHit.quality` now has three well-known values: `"generated"`, `"curated"`, and `"proposed"`. The first two appear in default search. Proposed assets are **excluded by default** — they only surface via `akm search ... --include-proposed` or via the `akm proposal *` commands. Unknown quality values parse-warn-include so plugin authors can extend the set without breaking the indexer.
|
|
95
|
+
|
|
96
|
+
## `akm-bench` v1
|
|
97
|
+
|
|
98
|
+
Bench grows from a smoke test into a paired-utility framework:
|
|
99
|
+
|
|
100
|
+
- **Track A — paired noakm/akm runs.** For each task, bench runs your agent CLI twice (without and with akm available), captures per-tool-call utility, and emits a comparable score pair.
|
|
101
|
+
- **Track B — registry attribution.** Utility deltas are mapped back to specific `[origin//]type:name` refs so you can see which assets in your stash actually contributed to the improvement.
|
|
102
|
+
- **`akm-bench compare`** — aggregates paired runs into a delta report.
|
|
103
|
+
- **`akm-bench attribute`** — surfaces the per-ref attribution report.
|
|
104
|
+
|
|
105
|
+
```sh
|
|
106
|
+
akm-bench compare results/noakm results/akm
|
|
107
|
+
akm-bench attribute results/akm
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
The technical reference for `akm-bench` now lives in the standalone [itlackey/akm-bench](https://github.com/itlackey/akm-bench) repo.
|
|
111
|
+
|
|
112
|
+
## Security hardening (PR #275)
|
|
113
|
+
|
|
114
|
+
Five security, UX, and hygiene issues landed together in the pre-prod hardening batch:
|
|
115
|
+
|
|
116
|
+
**Security:**
|
|
117
|
+
- **#270 — git message sanitization.** Commit messages and remote URLs written by akm are sanitized to prevent shell-substitution and control-character injection through user-supplied content.
|
|
118
|
+
- **#271 — bench env isolation.** Each agent invocation in `akm-bench` runs in a scrubbed environment so host secrets don't leak into bench transcripts.
|
|
119
|
+
- **#272 — LLM body redact + npm tarball host validation.** Outbound LLM request/response bodies are redacted in error reporting before surfacing to stderr. `akm add npm:…` now validates the tarball download host against your configured npm registry instead of blindly following arbitrary `dist.tarball` URLs.
|
|
120
|
+
|
|
121
|
+
**UX:**
|
|
122
|
+
- **#273 — workflow noise gate, stashes deprecation warn, setup `--help`.** `akm workflow next/complete/status` no longer print spurious progress noise on quiet runs. Configs using the legacy `stashes[]` key now emit a single deprecation warning per process (was: per call site). `akm setup --help` renders the full help block.
|
|
123
|
+
|
|
124
|
+
**Hygiene:**
|
|
125
|
+
- **#274 — tsconfig + HF pin + shapes throw.** `tsconfig.json` now covers `tests/` so `bunx tsc --noEmit` catches test-file errors. The HF embeddings model is pinned to a specific revision. The output-shape registry now throws on a missing shape rather than silently falling back to `JSON.stringify`.
|
|
126
|
+
- **#276 — bench tmp redirect.** `akm-bench` no longer writes scratch state under `/tmp`; everything lands under `~/.cache/akm/bench/`.
|
|
127
|
+
|
|
128
|
+
## Upgrade
|
|
129
|
+
|
|
130
|
+
```sh
|
|
131
|
+
npm install -g akm-cli@0.7.0
|
|
132
|
+
# or
|
|
133
|
+
bun install -g akm-cli@0.7.0
|
|
134
|
+
# or from an existing install
|
|
135
|
+
akm upgrade
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
**Verify:**
|
|
139
|
+
|
|
140
|
+
```sh
|
|
141
|
+
akm info --format text # version 0.7.x
|
|
142
|
+
akm proposal list # queue starts empty — that's expected
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
**Try the new surfaces:**
|
|
146
|
+
|
|
147
|
+
```sh
|
|
148
|
+
akm setup # detects installed agent CLIs
|
|
149
|
+
akm config set llm.features.feedback_distillation true
|
|
150
|
+
akm distill memory:my-debugging-notes # produces a lesson proposal — doclint:ignore (historical — akm 0.7.0 release announcement; `distill` command + ref grammar both retired later)
|
|
151
|
+
akm proposal list
|
|
152
|
+
akm proposal accept <id>
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
No manual migration is required for users on 0.6.x with no `agent` or `llm.features` blocks configured. Everything new is opt-in.
|
|
156
|
+
|
|
157
|
+
Full historical details are in the [pre-1.0 migration plan](https://github.com/itlackey/akm/blob/b507e3d29b173b7e5d3a70cfa06265436cd94e50/docs/archive/pre-1.0-migration.md) (pinned to its last commit before the doc was retired) and the [0.7.0 release notes](https://github.com/itlackey/akm/blob/main/docs/migration/release-notes/0.7.0.md).
|
|
158
|
+
|
|
159
|
+
Full changelog at [CHANGELOG.md](https://github.com/itlackey/akm/blob/main/.github/CHANGELOG.md).
|