kiokuko 1.0.5 → 1.0.7
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/README.ja.md +27 -0
- package/README.ko.md +27 -0
- package/README.md +38 -4
- package/README.zh-CN.md +27 -0
- package/dist/agent-file/render.d.ts +1 -1
- package/dist/agent-file/render.d.ts.map +1 -1
- package/dist/agent-file/render.js +6 -3
- package/dist/agent-file/render.js.map +1 -1
- package/dist/akinator/instructions.d.ts +1 -1
- package/dist/akinator/instructions.d.ts.map +1 -1
- package/dist/akinator/instructions.js +1 -1
- package/dist/akinator/instructions.js.map +1 -1
- package/dist/context/delivery.d.ts.map +1 -1
- package/dist/context/delivery.js +5 -6
- package/dist/context/delivery.js.map +1 -1
- package/dist/context/scoped-broker.d.ts +1 -1
- package/dist/context/scoped-broker.d.ts.map +1 -1
- package/dist/context/scoped-broker.js +4 -2
- package/dist/context/scoped-broker.js.map +1 -1
- package/dist/embedding/javascript-backend.d.ts.map +1 -1
- package/dist/embedding/javascript-backend.js +9 -0
- package/dist/embedding/javascript-backend.js.map +1 -1
- package/dist/embedding/sqlite-vec-backend.d.ts.map +1 -1
- package/dist/embedding/sqlite-vec-backend.js +9 -0
- package/dist/embedding/sqlite-vec-backend.js.map +1 -1
- package/dist/embedding/types.d.ts +1 -0
- package/dist/embedding/types.d.ts.map +1 -1
- package/dist/ledger/checkpoint-contract.d.ts +1 -1
- package/dist/ledger/checkpoint-contract.d.ts.map +1 -1
- package/dist/ledger/checkpoint-contract.js +1 -1
- package/dist/ledger/checkpoint-contract.js.map +1 -1
- package/dist/mcp/request-deadline.d.ts +1 -1
- package/dist/mcp/request-deadline.d.ts.map +1 -1
- package/dist/mcp/request-deadline.js +1 -0
- package/dist/mcp/request-deadline.js.map +1 -1
- package/dist/mcp/server.d.ts +1 -0
- package/dist/mcp/server.d.ts.map +1 -1
- package/dist/mcp/server.js +23 -2
- package/dist/mcp/server.js.map +1 -1
- package/dist/memory/federated-retrieval.d.ts +11 -1
- package/dist/memory/federated-retrieval.d.ts.map +1 -1
- package/dist/memory/federated-retrieval.js +25 -7
- package/dist/memory/federated-retrieval.js.map +1 -1
- package/dist/memory/hybrid-retrieval.d.ts +1 -0
- package/dist/memory/hybrid-retrieval.d.ts.map +1 -1
- package/dist/memory/hybrid-retrieval.js +10 -0
- package/dist/memory/hybrid-retrieval.js.map +1 -1
- package/dist/memory/interaction-capture.d.ts +19 -0
- package/dist/memory/interaction-capture.d.ts.map +1 -0
- package/dist/memory/interaction-capture.js +147 -0
- package/dist/memory/interaction-capture.js.map +1 -0
- package/dist/memory/interaction-contract.d.ts +142 -0
- package/dist/memory/interaction-contract.d.ts.map +1 -0
- package/dist/memory/interaction-contract.js +51 -0
- package/dist/memory/interaction-contract.js.map +1 -0
- package/dist/memory/interaction-fingerprint.d.ts +11 -0
- package/dist/memory/interaction-fingerprint.d.ts.map +1 -0
- package/dist/memory/interaction-fingerprint.js +49 -0
- package/dist/memory/interaction-fingerprint.js.map +1 -0
- package/dist/memory/interaction-recall.d.ts +31 -0
- package/dist/memory/interaction-recall.d.ts.map +1 -0
- package/dist/memory/interaction-recall.js +71 -0
- package/dist/memory/interaction-recall.js.map +1 -0
- package/dist/memory/interaction-subjects.d.ts +9 -0
- package/dist/memory/interaction-subjects.d.ts.map +1 -0
- package/dist/memory/interaction-subjects.js +35 -0
- package/dist/memory/interaction-subjects.js.map +1 -0
- package/dist/memory/lifecycle.d.ts +1 -0
- package/dist/memory/lifecycle.d.ts.map +1 -1
- package/dist/memory/lifecycle.js +19 -18
- package/dist/memory/lifecycle.js.map +1 -1
- package/dist/memory/rebuild-search.d.ts.map +1 -1
- package/dist/memory/rebuild-search.js +2 -0
- package/dist/memory/rebuild-search.js.map +1 -1
- package/dist/memory/retrieval.d.ts +1 -0
- package/dist/memory/retrieval.d.ts.map +1 -1
- package/dist/memory/retrieval.js.map +1 -1
- package/dist/memory/structured-memory.d.ts.map +1 -1
- package/dist/memory/structured-memory.js +8 -0
- package/dist/memory/structured-memory.js.map +1 -1
- package/dist/setup/render.d.ts.map +1 -1
- package/dist/setup/render.js +5 -2
- package/dist/setup/render.js.map +1 -1
- package/dist/setup/standard-skills.d.ts +7 -0
- package/dist/setup/standard-skills.d.ts.map +1 -1
- package/dist/setup/standard-skills.js +13 -0
- package/dist/setup/standard-skills.js.map +1 -1
- package/docs/README.ja.md +1 -0
- package/docs/README.md +2 -0
- package/docs/client-compatibility.md +9 -0
- package/docs/database.md +4 -0
- package/docs/interaction-memory-validation.md +108 -0
- package/docs/interaction-memory.md +121 -0
- package/migrations/003_interaction_memory.sql +17 -0
- package/package.json +6 -2
- package/skills/kiokuko-soul/SKILL.md +46 -3
- package/skills/memory-reasoning/SKILL.md +12 -0
- package/skills/one-shot-software-completion/SKILL.md +54 -0
- package/skills/one-shot-software-completion/references/boundaries-and-lifecycle.md +56 -0
- package/skills/one-shot-software-completion/references/discovery-and-scope.md +67 -0
- package/skills/one-shot-software-completion/references/failure-recovery.md +43 -0
- package/skills/one-shot-software-completion/references/verification-and-completion.md +62 -0
- package/templates/AGENTS.md +7 -5
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
# Interaction memory validation
|
|
2
|
+
|
|
3
|
+
Validated locally on 2026-09-19, macOS arm64, Node.js 26.5.0. These are source and
|
|
4
|
+
isolated-install results, not a published release or an update to a running client.
|
|
5
|
+
|
|
6
|
+
## Automated checks
|
|
7
|
+
|
|
8
|
+
- TypeScript type checking, build, and the 1,685-test unit/integration suite pass.
|
|
9
|
+
- Retrieval evaluation: 110 queries, Recall@1 0.93, Recall@5 0.99, semantic-only
|
|
10
|
+
Recall@5 0.95, zero scope leaks, zero false-negative deliveries. These use the
|
|
11
|
+
existing deterministic evaluation corpus, not a claim about model behavior.
|
|
12
|
+
- Package dry-run includes migration 003, the two tools, updated Skills, templates,
|
|
13
|
+
and documentation. Isolated global installation verifies bundled Skill setup
|
|
14
|
+
across Codex, Claude Code, OpenCode, and Hermes.
|
|
15
|
+
- The schema-3 sample database passes baseline and Web API checks. A separate v2
|
|
16
|
+
upgrade test verifies that old entries and revision bytes are not reclassified.
|
|
17
|
+
- New tests cover standalone global operation without project state, subject
|
|
18
|
+
isolation, general preference injection, capability withholding, exact replay,
|
|
19
|
+
restarted connections, concurrent processes, operation conflicts, corrections
|
|
20
|
+
of verified memories, stale/ambiguous/protected targets, transactional failure,
|
|
21
|
+
secret rejection, purge retries, candidate edits, import, and index rebuilding.
|
|
22
|
+
- Both vector backends apply explicit subject filters before their candidate
|
|
23
|
+
limit. The regression places the matching entry behind 130 unrelated vectors.
|
|
24
|
+
- Project preference ranking uses `context-ranking-v7`, preventing replay of a
|
|
25
|
+
context selected under the previous ranking policy. Historical deliveries remain
|
|
26
|
+
readable; existing revision hashes are unchanged.
|
|
27
|
+
|
|
28
|
+
The first sandboxed suite could not bind local HTTP ports. The passing suite ran
|
|
29
|
+
with localhost access. Package installation used a temporary prefix and npm cache;
|
|
30
|
+
no user client configuration was rewritten.
|
|
31
|
+
|
|
32
|
+
## Live model behavior
|
|
33
|
+
|
|
34
|
+
| Client | Result | Evidence / limit |
|
|
35
|
+
|---|---|---|
|
|
36
|
+
| Codex CLI 0.153.4 | Passed | Two fresh ephemeral conversations, real stdio MCP and a disposable SQLite database. The model chose capture, then recalled and used the preference. |
|
|
37
|
+
| Claude Code 2.1.220 | Blocked before inference | The isolated `--bare` probe reported `authentication_failed` / “Not logged in”. Bare mode intentionally does not use OAuth/keychain credentials. This does not establish the login state of the normal installed profile. |
|
|
38
|
+
| OpenCode 1.18.31 | Blocked before inference | The isolated config/data probe reported `ProviderAuthError`: its selected Google provider had no API key. Normal-profile authentication was not copied or inspected. |
|
|
39
|
+
| Hermes Agent | Not run | No `hermes` executable on the test process PATH. No conclusion about installations elsewhere. |
|
|
40
|
+
|
|
41
|
+
Codex's first natural message was:
|
|
42
|
+
|
|
43
|
+
> For Japanese grammar explanations, I prefer two examples about trains before grammatical terminology.
|
|
44
|
+
|
|
45
|
+
Its `memory_capture` call created a global candidate with subject
|
|
46
|
+
`japanese-grammar`. The second conversation received only this new message:
|
|
47
|
+
|
|
48
|
+
> Explain the difference between は and が in Japanese grammar.
|
|
49
|
+
|
|
50
|
+
The model used query-only `memory_recall`. Its answer gave these two train examples
|
|
51
|
+
before explaining topic and subject terminology:
|
|
52
|
+
|
|
53
|
+
> 電車は来ました。 — “The train has arrived.”
|
|
54
|
+
>
|
|
55
|
+
> 電車が来ました。 — “A train has arrived” or “The train is here.”
|
|
56
|
+
|
|
57
|
+
Both conversations read only their local copies of the bundled Skills. The second
|
|
58
|
+
had no first-conversation transcript or preference in its prompt. Database checks
|
|
59
|
+
confirmed zero repository locations, task runs, and intake sessions. This is live
|
|
60
|
+
proof of capture and later influence in Codex under the tested setup; it does not
|
|
61
|
+
prove every-turn interception or reliability in the other clients.
|
|
62
|
+
|
|
63
|
+
Two earlier probes exposed real integration boundaries. First, noninteractive
|
|
64
|
+
Codex denied the write tool under its approval policy. The test now preapproves
|
|
65
|
+
only its disposable server's `memory_capture` operation. Second, model-generated
|
|
66
|
+
labels differed (“Japanese grammar explanations” vs “Japanese grammar”), causing
|
|
67
|
+
an exact-filter miss. Bundled guidance now favors short topic labels and query-only
|
|
68
|
+
recall unless exact stored labels are known. The successful probe used that guidance.
|
|
69
|
+
Host/client tool approval still applies; Kiokuko does not bypass it.
|
|
70
|
+
|
|
71
|
+
Reproduce the Codex probe with an already-authenticated CLI:
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
npm run test:interaction:live
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
The script prints its temporary evidence directory, preserves protocol events and
|
|
78
|
+
answers there, and fails unless capture, later recall, and the train preference in
|
|
79
|
+
the second answer are observed. It uses process-only configuration, disables
|
|
80
|
+
native memory injection, ignores user config, and never resumes an old conversation.
|
|
81
|
+
It does not install or log into clients. For the other clients, use the same two
|
|
82
|
+
natural messages in separate fresh sessions with a disposable Kiokuko database,
|
|
83
|
+
then verify both tool calls and the second answer before marking them passed.
|
|
84
|
+
|
|
85
|
+
Codex configuration follows the official [configuration reference](https://learn.chatgpt.com/docs/config-file/config-reference)
|
|
86
|
+
and [noninteractive mode guide](https://learn.chatgpt.com/docs/non-interactive-mode).
|
|
87
|
+
OpenCode isolation used its documented [CLI environment settings](https://opencode.ai/docs/cli/).
|
|
88
|
+
|
|
89
|
+
## Measured scale
|
|
90
|
+
|
|
91
|
+
The interaction benchmark seeds 10,000 synthetic global captured facts in
|
|
92
|
+
**in-memory SQLite**, with embeddings disabled. It uses 10 recall/duplicate-capture
|
|
93
|
+
samples and 3 snapshot samples; values below are local measurements, not an SLA.
|
|
94
|
+
|
|
95
|
+
| Operation | Median | p95 |
|
|
96
|
+
|---|---:|---:|
|
|
97
|
+
| Query plus explicit subject recall | 27.47 ms | 35.32 ms |
|
|
98
|
+
| Exact duplicate capture | 0.38 ms | 2.56 ms |
|
|
99
|
+
| Existing project-context snapshot hash over 10,000 relevant entries | 1,447.14 ms | 1,469.49 ms |
|
|
100
|
+
|
|
101
|
+
Seeding took 8.29 seconds. The same snapshot path rejects 10,001 entries with its
|
|
102
|
+
existing integrity error. The snapshot measurement is one component of project
|
|
103
|
+
preparation, not the duration of a full `task_prepare`. Disk latency, providers,
|
|
104
|
+
large receipt histories, and long-running task ledgers were not benchmarked here.
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
npm run test:interaction:benchmark
|
|
108
|
+
```
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
# Memory from normal interaction
|
|
2
|
+
|
|
3
|
+
Kiokuko can save durable preferences, facts, decisions, and corrections from normal
|
|
4
|
+
conversation. The current client's model extracts concise memories and calls
|
|
5
|
+
`memory_capture`; no separate model service or credentials are needed. Each memory
|
|
6
|
+
is a revisioned SQLite entry. Automatic saves are **candidate / untrusted**, and
|
|
7
|
+
can immediately be recalled as advisory context. A stated evidence basis is not
|
|
8
|
+
proof of truth. Curator's reviewed global promotion remains a separate operation.
|
|
9
|
+
|
|
10
|
+
After updating Kiokuko, run `kiokuko setup` for your selected clients and restart
|
|
11
|
+
them so the new tools and bundled instructions load. Existing project work still
|
|
12
|
+
uses `task_prepare` / `task_answer`. General conversation uses `memory_recall`
|
|
13
|
+
without a repository, task run, or artificial intake answers.
|
|
14
|
+
|
|
15
|
+
## What is saved
|
|
16
|
+
|
|
17
|
+
The model is instructed to capture explicit durable preferences and corrections,
|
|
18
|
+
settled decisions, verified results, and reusable troubleshooting lessons—even
|
|
19
|
+
without “remember this.” It skips routine progress, temporary requests, repetition,
|
|
20
|
+
unsupported assistant conclusions, sensitive personal profiling, and transcripts.
|
|
21
|
+
Secret detection rejects a whole batch before it writes anything.
|
|
22
|
+
|
|
23
|
+
Clearly general knowledge can be saved globally with a portability reason.
|
|
24
|
+
Project-specific knowledge requires the active project run after intake permits
|
|
25
|
+
progress. Uncertain scope stays local or is skipped outside a project. General
|
|
26
|
+
communication preferences must be explicitly general; subject preferences retain
|
|
27
|
+
their subjects. Memories never authorize actions or override current instructions.
|
|
28
|
+
|
|
29
|
+
## MCP contract
|
|
30
|
+
|
|
31
|
+
`memory_capture` is non-terminal. Its input includes `operationId`, optional
|
|
32
|
+
`cwd` / `runId`, and one to five `memories`. Each item reuses the checkpoint fields
|
|
33
|
+
(kind, title, body, scope, applicability, tags, and portability reason), with:
|
|
34
|
+
|
|
35
|
+
- `body`: nonempty, at most 2,000 characters; optional summary at most 500.
|
|
36
|
+
- `subjects`: one to five labels, normalized to lowercase `subject:` tags.
|
|
37
|
+
- `basis`: `user_statement`, `user_correction`, or `observed_result`.
|
|
38
|
+
- `generalCommunication: true`: only for an unqualified global preference;
|
|
39
|
+
omit subjects and applicability in this case.
|
|
40
|
+
- `replaces: { entryId, expectedRevision }`: only with `user_correction`.
|
|
41
|
+
|
|
42
|
+
For example, a model can extract this from “When explaining Japanese grammar,
|
|
43
|
+
I prefer examples before terminology”:
|
|
44
|
+
|
|
45
|
+
```json
|
|
46
|
+
{
|
|
47
|
+
"operationId": "conversation-1-preference-1",
|
|
48
|
+
"memories": [{
|
|
49
|
+
"kind": "preference",
|
|
50
|
+
"title": "Japanese grammar explanations",
|
|
51
|
+
"body": "For Japanese grammar explanations, give examples before terminology.",
|
|
52
|
+
"scope": "global",
|
|
53
|
+
"portableReason": "Applies to Japanese grammar explanations across projects.",
|
|
54
|
+
"subjects": ["Japanese grammar"],
|
|
55
|
+
"basis": "user_statement"
|
|
56
|
+
}]
|
|
57
|
+
}
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Responses contain entry IDs, revisions, workspace, created/duplicate/corrected
|
|
61
|
+
outcomes, and current/changed/superseded/unavailable availability. Reuse an
|
|
62
|
+
operation ID only for an exact retry; a different payload conflicts. Exact
|
|
63
|
+
normalized content across separate operations deduplicates independently of
|
|
64
|
+
timestamps, client provenance, and run IDs. Similar paraphrases are not merged.
|
|
65
|
+
|
|
66
|
+
Corrections require an exact current revision in the same scope. Creating the
|
|
67
|
+
replacement and superseding the old entry is atomic, including for a previously
|
|
68
|
+
verified entry. History remains accessible through existing review controls.
|
|
69
|
+
Stale revisions, duplicate correction targets, and managed entries are rejected.
|
|
70
|
+
Operation receipts contain no memory text. Retrying a purged operation acknowledges
|
|
71
|
+
its unavailable entry without recreating it. A new operation ID is a new request,
|
|
72
|
+
not a deletion tombstone bypass prevention mechanism.
|
|
73
|
+
|
|
74
|
+
`memory_recall` takes `soulRead: true`, the complete current capability catalog,
|
|
75
|
+
`query`, optional `subjects`, `limit` (default 8, maximum 20), and
|
|
76
|
+
`maxContextChars` (default 4,000, range 100–12,000). Read the exact local
|
|
77
|
+
`kiokuko-soul` and `memory-reasoning` Skills before advertising them. Missing SOUL
|
|
78
|
+
blocks recall; missing or unknown memory-reasoning withholds ordinary memories.
|
|
79
|
+
Current managed Curator projections retain the existing trusted-memory exception.
|
|
80
|
+
|
|
81
|
+
Recall searches only global memory, using lexical and optional semantic retrieval.
|
|
82
|
+
Explicit subjects restrict matching before result selection. Without explicit
|
|
83
|
+
subjects, at most two general communication preferences may appear without query
|
|
84
|
+
word overlap. Subject preferences require the subject in the query or an explicit
|
|
85
|
+
subject filter. Prefer query-only recall. Pass explicit filters only for exact known stored labels,
|
|
86
|
+
not guessed synonyms. Use short topic labels at capture time. Project preparation
|
|
87
|
+
uses the same preference selection within its existing budget and capability gate.
|
|
88
|
+
Returned records include IDs, revisions, subjects, status/trust labels, and concise
|
|
89
|
+
content. The character budget includes the serialized memory items, not protocol
|
|
90
|
+
or capability metadata.
|
|
91
|
+
|
|
92
|
+
Save important corrections promptly; batch other captures before the final answer.
|
|
93
|
+
Do not resubmit captured memories in `memory_checkpoint`, which remains terminal.
|
|
94
|
+
|
|
95
|
+
## Disable capture
|
|
96
|
+
|
|
97
|
+
Set the environment variable on the Kiokuko MCP server process, then restart it:
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
KIOKUKO_INTERACTION_MEMORY=off kiokuko mcp
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
In a client's MCP configuration, put `KIOKUKO_INTERACTION_MEMORY = "off"` in its
|
|
104
|
+
server environment rather than starting a second server manually. Recall and
|
|
105
|
+
existing explicit checkpoints remain available. No new management UI is needed:
|
|
106
|
+
use the existing Web/CLI review, history, and deletion controls.
|
|
107
|
+
|
|
108
|
+
## Storage and limits
|
|
109
|
+
|
|
110
|
+
Migration `003_interaction_memory.sql` adds an indexed fingerprint projection.
|
|
111
|
+
Revision hashes keep their original provenance-sensitive definition. Candidate
|
|
112
|
+
edits, imports, superseding, purge, and search-index rebuilding maintain the
|
|
113
|
+
projection. Existing memories are not automatically reclassified. Receipts are
|
|
114
|
+
local operational metadata; workspace exports include memories, not retry history.
|
|
115
|
+
|
|
116
|
+
One database represents one user. Capture is model-mediated and cannot intercept
|
|
117
|
+
every turn. SQLite capacity is not a promise of unlimited project retrieval: the
|
|
118
|
+
existing 10,000-entry project snapshot integrity limit remains in force.
|
|
119
|
+
|
|
120
|
+
See [interaction memory validation](interaction-memory-validation.md) for automated
|
|
121
|
+
checks, performance measurements, and separate live-client results.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
-- A rebuildable projection, not a replacement for immutable revision hashes.
|
|
2
|
+
CREATE TABLE interaction_memory_fingerprints (
|
|
3
|
+
entry_id TEXT PRIMARY KEY REFERENCES entries(id) ON DELETE CASCADE,
|
|
4
|
+
workspace TEXT NOT NULL,
|
|
5
|
+
revision INTEGER NOT NULL CHECK (revision > 0),
|
|
6
|
+
fingerprint TEXT NOT NULL CHECK (length(fingerprint) = 64),
|
|
7
|
+
FOREIGN KEY (entry_id, revision) REFERENCES entry_revisions(entry_id, revision) ON DELETE CASCADE
|
|
8
|
+
);
|
|
9
|
+
CREATE INDEX idx_interaction_memory_fingerprint
|
|
10
|
+
ON interaction_memory_fingerprints(workspace, fingerprint, entry_id);
|
|
11
|
+
|
|
12
|
+
CREATE TRIGGER interaction_memory_invalidate
|
|
13
|
+
AFTER UPDATE OF current_revision, status ON entries
|
|
14
|
+
WHEN NEW.current_revision <> OLD.current_revision OR NEW.status = 'superseded'
|
|
15
|
+
BEGIN
|
|
16
|
+
DELETE FROM interaction_memory_fingerprints WHERE entry_id = NEW.id;
|
|
17
|
+
END;
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "kiokuko",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.7",
|
|
4
4
|
"description": "Model-agnostic external memory for AI coding agents",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -35,6 +35,8 @@
|
|
|
35
35
|
"test:sqlite-vec": "node --import tsx tests/ci/sqlite-vec-package-smoke.ts",
|
|
36
36
|
"test:global-install": "node tests/ci/global-install-smoke.mjs",
|
|
37
37
|
"test:evaluation": "npm run build && node scripts/run-retrieval-evaluation.mjs",
|
|
38
|
+
"test:interaction:live": "npm run build && node scripts/run-interaction-memory-smoke.mjs",
|
|
39
|
+
"test:interaction:benchmark": "npm run build && node scripts/run-interaction-memory-benchmark.mjs",
|
|
38
40
|
"test:benchmark": "npm run build && node scripts/run-retrieval-benchmark.mjs",
|
|
39
41
|
"sampledb:generate": "node --import tsx tests/fixtures/sample-database.ts tests/sampledb/kiokuko.sqlite3",
|
|
40
42
|
"test:sampledb": "npm run build && node --import tsx tests/ci/verify-sample-database.ts",
|
|
@@ -58,7 +60,9 @@
|
|
|
58
60
|
"allowScripts": {
|
|
59
61
|
"onnxruntime-node": true,
|
|
60
62
|
"sharp": true,
|
|
61
|
-
"protobufjs": true
|
|
63
|
+
"protobufjs": true,
|
|
64
|
+
"esbuild@0.28.2": true,
|
|
65
|
+
"fsevents@2.3.3": true
|
|
62
66
|
},
|
|
63
67
|
"peerDependencies": {
|
|
64
68
|
"@huggingface/hub": "2.16.1",
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: kiokuko-soul
|
|
3
|
-
description: Use before every non-trivial Kiokuko-governed task as the mandatory first-read SOUL router. Run the Akinator intake gate before planning or implementation, then route simple code work, general code work, and interactive UI work to the bundled specialist Skills.
|
|
3
|
+
description: Use before every coding request, including small fixes, and every other non-trivial Kiokuko-governed task as the mandatory first-read SOUL router. Run the Akinator intake gate before planning or implementation, then route simple code work, general code work, and interactive UI work to the bundled specialist Skills.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
<!-- KIOKUKO MANAGED STANDARD SKILL: kiokuko-soul -->
|
|
@@ -9,7 +9,7 @@ description: Use before every non-trivial Kiokuko-governed task as the mandatory
|
|
|
9
9
|
|
|
10
10
|
## Outcome
|
|
11
11
|
|
|
12
|
-
Start every non-trivial Kiokuko-governed task by reading one stable router, resolving the Akinator intake gate, then reading the applicable compact specialist indexes and only the expert fragments required by the current task.
|
|
12
|
+
Start every coding request (including small fixes) and every other non-trivial Kiokuko-governed task by reading one stable router, resolving the Akinator intake gate, then reading the applicable compact specialist indexes and only the expert fragments required by the current task.
|
|
13
13
|
|
|
14
14
|
This Skill owns the entry sequence and routes work. Akinator is the mandatory intake state machine, not a specialist route. This Skill does not duplicate specialist instructions, select another model, or authorize effects beyond the user request and current client permissions.
|
|
15
15
|
|
|
@@ -17,6 +17,40 @@ This Skill owns the entry sequence and routes work. Akinator is the mandatory in
|
|
|
17
17
|
|
|
18
18
|
Explicit user instructions outrank these Skills' design, style, workflow, and implementation preferences. They do not override host-enforced safety, authorization, identity, state, revision, or integrity invariants. Resolve routine choices from repository evidence and existing authorization; ask only when an unresolved assumption would materially change the intended result or permitted effects.
|
|
19
19
|
|
|
20
|
+
## Ordinary conversation and interaction memory
|
|
21
|
+
|
|
22
|
+
For ordinary conversation that does not involve project work, use `memory_recall`
|
|
23
|
+
with the current query, optional subjects, `soulRead: true`, and the complete
|
|
24
|
+
capability catalog. Read `memory-reasoning` before advertising it. No repository,
|
|
25
|
+
task run, or Akinator answers are needed. This route cannot replace or bypass
|
|
26
|
+
intake for project work or an already-open project run.
|
|
27
|
+
|
|
28
|
+
Proactively use non-terminal `memory_capture` for durable user statements and
|
|
29
|
+
preferences, explicit corrections, settled decisions, and verified reusable
|
|
30
|
+
results, even without “remember this.” Extract at most five concise memories per
|
|
31
|
+
call with subjects and an honest basis. Use short topic labels such as “Japanese
|
|
32
|
+
grammar”, not task phrases such as “Japanese grammar explanations”. Prefer
|
|
33
|
+
query-only recall; pass subject filters only for exact known stored labels.
|
|
34
|
+
Save important corrections promptly and
|
|
35
|
+
batch other memories before the final answer. Save nothing when nothing is useful.
|
|
36
|
+
Skip routine progress, temporary requests, repetition, unsupported assistant
|
|
37
|
+
conclusions, sensitive personal profiling, secrets, and transcripts.
|
|
38
|
+
|
|
39
|
+
Project saves require the active run with completed intake. Clearly general
|
|
40
|
+
knowledge may use global scope with a portability reason. `generalCommunication`
|
|
41
|
+
is only for explicitly general communication preferences, without subjects or
|
|
42
|
+
applicability. Subject-specific preferences must retain their subjects. Correct
|
|
43
|
+
only a known entry ID and expected revision; never guess a replacement target.
|
|
44
|
+
All captures remain untrusted candidates, immediately eligible for advisory
|
|
45
|
+
recall. Curator still requires approval for verified global promotion.
|
|
46
|
+
|
|
47
|
+
`memory_capture` does not close the task. `memory_checkpoint` remains terminal;
|
|
48
|
+
do not repeat captured memories there. Exact transport retries reuse the capture
|
|
49
|
+
operation ID; changed payloads use a new operation. A purged receipt is not an
|
|
50
|
+
instruction to recreate content. `KIOKUKO_INTERACTION_MEMORY=off` disables capture
|
|
51
|
+
without disabling recall or explicit checkpoints. Tool use is model-mediated,
|
|
52
|
+
not a guarantee of interception on every turn.
|
|
53
|
+
|
|
20
54
|
## Required entry
|
|
21
55
|
|
|
22
56
|
Read this Skill before any other bundled Kiokuko Skill.
|
|
@@ -72,6 +106,14 @@ This route minimizes the solution; it does not replace the code contract below o
|
|
|
72
106
|
|
|
73
107
|
Read and apply the `kiokuko-single-purpose-functions` index before writing, modifying, debugging, refactoring, or reviewing code, and before decomposing a code-changing plan. Select one to three `code.*` expert fragments for each cohesive function or task.
|
|
74
108
|
|
|
109
|
+
### Software completion for every coding request
|
|
110
|
+
|
|
111
|
+
Before code-changing planning or implementation, apply the compact
|
|
112
|
+
`one-shot-software-completion/SKILL.md` core, including for small, minimal/YAGNI,
|
|
113
|
+
test and UI changes. Reuse its unchanged full text already in active context;
|
|
114
|
+
otherwise read it. A summary is insufficient. Load references only for concrete
|
|
115
|
+
risks; this route does not require reading them all. Follow availability rules below.
|
|
116
|
+
|
|
75
117
|
### Interactive UI work
|
|
76
118
|
|
|
77
119
|
Read and apply the `kiokuko-ui-design-soul` index before designing, implementing, modifying, debugging, or reviewing an interactive interface. Select one to three `ui.*` expert fragments for the actual interaction risks. If UI work changes code, apply both the code and UI indexes.
|
|
@@ -87,7 +129,8 @@ Use this order:
|
|
|
87
129
|
3. `veteran-programmer-skill` when the change crosses workflow stages;
|
|
88
130
|
4. `kiokuko-simple-work` when the finalized intake satisfies the simple-code activation boundary;
|
|
89
131
|
5. `kiokuko-single-purpose-functions` for code planning or code work;
|
|
90
|
-
6. `
|
|
132
|
+
6. `one-shot-software-completion` for every coding request, including simple code and UI code changes;
|
|
133
|
+
7. `kiokuko-ui-design-soul` for interactive UI work.
|
|
91
134
|
|
|
92
135
|
Keep each route within the user-approved task scope.
|
|
93
136
|
|
|
@@ -35,6 +35,18 @@ When Kiokuko delivers ordinary memory for a build or debug task:
|
|
|
35
35
|
evidence is enough.
|
|
36
36
|
7. Prefer current verified evidence when it conflicts with recalled material.
|
|
37
37
|
|
|
38
|
+
## General conversation
|
|
39
|
+
|
|
40
|
+
Read this Skill before advertising it to `memory_recall`. Use retrieved
|
|
41
|
+
preferences only for the matching subject. Prefer query-only recall and do not
|
|
42
|
+
guess exact subject filters. The exception is explicitly general
|
|
43
|
+
communication preferences. Respect the entry's status, trust level, subjects,
|
|
44
|
+
and revision. Current user instructions override remembered preferences; a
|
|
45
|
+
memory never grants permission. A stated evidence basis is a model claim, not
|
|
46
|
+
independent verification. Check changing factual claims against current sources.
|
|
47
|
+
For explicit user corrections, pass the recalled entry ID and expected revision
|
|
48
|
+
to `memory_capture`; do not overwrite an ambiguous target.
|
|
49
|
+
|
|
38
50
|
## Trust and safety boundaries
|
|
39
51
|
|
|
40
52
|
- Treat ordinary memory, external references, and past conclusions as advisory
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: one-shot-software-completion
|
|
3
|
+
description: Required before planning or implementing any code change, including small fixes, tests and UI. Read this compact core; load references only for concrete risks.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- KIOKUKO MANAGED STANDARD SKILL: one-shot-software-completion -->
|
|
7
|
+
|
|
8
|
+
<!-- kiokuko:runtime contract -->
|
|
9
|
+
# One-Shot Software Completion
|
|
10
|
+
|
|
11
|
+
Deliver the user's observable result, not an isolated patch. One-shot is a
|
|
12
|
+
delivery goal, not a promise of success in one turn or extra authorization.
|
|
13
|
+
|
|
14
|
+
## Activation and context
|
|
15
|
+
|
|
16
|
+
For every coding request, including minimal/YAGNI work, apply this entire core
|
|
17
|
+
before code-changing planning or implementation. Follow `kiokuko-soul` and host
|
|
18
|
+
intake, scope and permissions; this Skill grants no extra agents or continuation.
|
|
19
|
+
Reuse the unchanged full core already in active context, including host-supplied
|
|
20
|
+
text. Read it when absent, changed or lost to compaction; a summary or capability
|
|
21
|
+
listing is insufficient. Reuse the existing plan and evidence, not extra checklists.
|
|
22
|
+
|
|
23
|
+
## Completion contract
|
|
24
|
+
|
|
25
|
+
1. Define the observable result. Resolve routine choices from current repository
|
|
26
|
+
evidence; ask only about consequential uncertainty in intent or authorization.
|
|
27
|
+
2. Trace the real entry point, callers and effects. Include required wiring,
|
|
28
|
+
delivery steps and checks; preserve unrelated work and compatibility.
|
|
29
|
+
3. Make the smallest complete change. Handle relevant boundaries, errors,
|
|
30
|
+
security and resource ownership. Define expected results before implementation;
|
|
31
|
+
add regression coverage for material behavior, reuse adequate existing checks.
|
|
32
|
+
4. Run required checks and focused verification through the changed entry point.
|
|
33
|
+
Broaden for shared contracts; rerun checks invalidated by edits. A helper test
|
|
34
|
+
alone does not prove delivery. Never weaken checks to hide failure.
|
|
35
|
+
5. Review the complete diff, including new files. Report behavior, checks/results,
|
|
36
|
+
assumptions and unverified paths. Distinguish source from deployed/runtime
|
|
37
|
+
evidence. Continue authorized work; stop only on completion or a concrete blocker.
|
|
38
|
+
|
|
39
|
+
## Read only for the current risk
|
|
40
|
+
|
|
41
|
+
A bounded change with clear callers and checks needs only this core. Otherwise
|
|
42
|
+
read the matching reference, one at a time; never preload the set or reread merely
|
|
43
|
+
because the phase changed. Select repository excerpts by relevant symbols/ranges.
|
|
44
|
+
|
|
45
|
+
| Read when | Reference |
|
|
46
|
+
| --- | --- |
|
|
47
|
+
| Scope, callers or integration are unclear | [Discovery](references/discovery-and-scope.md) |
|
|
48
|
+
| Inputs, effects, lifetime or compatibility change | [Boundaries](references/boundaries-and-lifecycle.md) |
|
|
49
|
+
| Evidence or delivery is uncertain | [Verification](references/verification-and-completion.md) |
|
|
50
|
+
| A check fails or progress stalls; before changing strategy | [Recovery](references/failure-recovery.md) |
|
|
51
|
+
|
|
52
|
+
Never retry an unchanged failed operation. Reference deferral does not waive the
|
|
53
|
+
core obligations. Follow the router's other applicable contracts without duplicating them.
|
|
54
|
+
<!-- /kiokuko:runtime -->
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
<!-- KIOKUKO MANAGED STANDARD SKILL: one-shot-software-completion -->
|
|
2
|
+
|
|
3
|
+
# Boundaries and lifecycle
|
|
4
|
+
|
|
5
|
+
Use when changing input acceptance, effects, state or a public/stored contract.
|
|
6
|
+
Apply the code Skill's selected experts; this reference helps find omissions
|
|
7
|
+
across the workflow rather than replacing those contracts.
|
|
8
|
+
|
|
9
|
+
## Derive cases from the actual contract
|
|
10
|
+
|
|
11
|
+
Select relevant boundaries; do not build an exhaustive speculative matrix.
|
|
12
|
+
Each selected case needs deliberate accept/reject behavior or a demonstrated
|
|
13
|
+
upstream invariant. A type assertion alone does not validate external input.
|
|
14
|
+
|
|
15
|
+
| Input or boundary | Candidate cases |
|
|
16
|
+
| --- | --- |
|
|
17
|
+
| Text | absent, empty/whitespace, Unicode, length limit, injection-shaped content |
|
|
18
|
+
| Numbers | zero, negative, bounds, fractional/non-finite values, encoded strings |
|
|
19
|
+
| Collections | empty, singleton, duplicates, order, size limits |
|
|
20
|
+
| Optional fields | missing, null, undefined, present but empty |
|
|
21
|
+
| Identity | nonexistent, deleted, stale, another user/tenant's resource |
|
|
22
|
+
| Time | zone/offset, DST, epoch zero, skew, expiry boundary |
|
|
23
|
+
| Concurrent work | duplicate/out-of-order request, cancellation, partial batch |
|
|
24
|
+
|
|
25
|
+
Example: pagination needs a defined limit range and integer policy, stable
|
|
26
|
+
ordering, cursor behavior and tenant isolation. Whether an unknown cursor is an
|
|
27
|
+
error or an empty page comes from the API contract, not this checklist.
|
|
28
|
+
|
|
29
|
+
## Decide effects and failure semantics
|
|
30
|
+
|
|
31
|
+
For each changed network, filesystem, database or process boundary, identify
|
|
32
|
+
ownership, timeout/cancellation, public error and partial-success behavior.
|
|
33
|
+
Reuse the repository policy; avoid silent catches or a success result after a
|
|
34
|
+
required effect failed. Retries require an idempotent operation or a verified
|
|
35
|
+
deduplication contract, bounded attempts and preserved request identity.
|
|
36
|
+
|
|
37
|
+
A timeout after a write may mean the effect succeeded but its acknowledgment
|
|
38
|
+
was lost. Do not resend a charge, notification or mutation merely because the
|
|
39
|
+
response is absent. Reconcile uncertain state through the supported mechanism.
|
|
40
|
+
|
|
41
|
+
For each resource or state holder, trace creation, access, invalidation, cleanup,
|
|
42
|
+
restart/reload and test teardown. Account for subscriptions, timers, locks,
|
|
43
|
+
caches and background jobs. Preserve transaction and rollback boundaries;
|
|
44
|
+
cancellation of a UI is not proof that the underlying operation stopped.
|
|
45
|
+
|
|
46
|
+
## Preserve consumers
|
|
47
|
+
|
|
48
|
+
Identify contracts that leave this patch: JSON, database rows, queue messages,
|
|
49
|
+
exports, CLI flags, config and environment variables. Preserve existing behavior
|
|
50
|
+
by default. When a breaking change is requested, include its migration/version
|
|
51
|
+
and downstream update strategy within authorized scope.
|
|
52
|
+
|
|
53
|
+
Adding an optional field with a safe default may preserve compatibility;
|
|
54
|
+
renaming, deleting, changing type or redefining defaults may not. Test old data
|
|
55
|
+
and callers where they remain supported. Check readers as well as writers and
|
|
56
|
+
rollout/restart ordering when old and new versions can coexist.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
<!-- KIOKUKO MANAGED STANDARD SKILL: one-shot-software-completion -->
|
|
2
|
+
|
|
3
|
+
# Discovery and scope
|
|
4
|
+
|
|
5
|
+
Use when the behavioral requirement, caller graph or patch boundary is unclear.
|
|
6
|
+
Keep decisions in the existing plan; a separate document is not required.
|
|
7
|
+
|
|
8
|
+
## Reconstruct the requirement
|
|
9
|
+
|
|
10
|
+
- Express the requested result as observable input, action and output. "Add
|
|
11
|
+
pagination" needs an entry point, response shape, ordering, defaults and
|
|
12
|
+
compatibility with existing callers, not just a pagination helper.
|
|
13
|
+
- Resolve unspecified choices from a working analog, project instructions and
|
|
14
|
+
conventions, then the framework idiom already used locally. Prefer the least
|
|
15
|
+
disruptive reversible choice and record material assumptions. Explicit user
|
|
16
|
+
requirements outrank inferred conventions.
|
|
17
|
+
- Repository evidence cannot answer every ambiguity. Ask when competing
|
|
18
|
+
interpretations materially change the requested result, data, public contract
|
|
19
|
+
or permissions. Complete independent work while a necessary answer is pending.
|
|
20
|
+
Do not treat naming or formatting choices with established defaults as blockers.
|
|
21
|
+
|
|
22
|
+
## Trace before editing
|
|
23
|
+
|
|
24
|
+
Follow entry point -> target -> callees/effects -> callers/consumers. Search
|
|
25
|
+
changed symbols and serialized field names; the compiler cannot find untyped
|
|
26
|
+
fixtures, external consumers or dynamic registrations. Inspect tests and the
|
|
27
|
+
actual check commands. Check imports, module state, exports and nearby helpers
|
|
28
|
+
in contiguous reads; read the whole file when its contract depends on them.
|
|
29
|
+
Avoid recursively reading every transitive dependency without a concrete risk.
|
|
30
|
+
|
|
31
|
+
Use the closest maintained analog for placement, registration, errors, config,
|
|
32
|
+
tests and docs. Recency alone does not make an example correct. Preserve existing
|
|
33
|
+
dependency direction and use local validation, HTTP, IDs, retry and test helpers
|
|
34
|
+
before adding another implementation or dependency.
|
|
35
|
+
|
|
36
|
+
## Find the required accompanying changes
|
|
37
|
+
|
|
38
|
+
From the actual workflow, identify relevant types, validation, serialization,
|
|
39
|
+
permissions, flags, UI strings, CLI help/API docs, fixtures, exports, registration,
|
|
40
|
+
migrations and generated artifacts. Logging and changelog entries are required
|
|
41
|
+
only when the task or repository requires them. For setup and delivery, follow
|
|
42
|
+
the artifact to its consumer and reload trigger with `veteran-programmer-skill`.
|
|
43
|
+
|
|
44
|
+
Example: a new notification provider may require its client/schema, registry
|
|
45
|
+
entry and configuration validation. A provider class tested only in isolation
|
|
46
|
+
does not prove users can select it.
|
|
47
|
+
|
|
48
|
+
## Bound and plan the patch
|
|
49
|
+
|
|
50
|
+
- Include every step required to make the behavior reachable and correct. A
|
|
51
|
+
smaller diff is a tiebreaker between complete solutions.
|
|
52
|
+
- Follow changed contracts through types, stored/wire data, callers, fixtures
|
|
53
|
+
and docs. Keep compatibility where consumers cannot change in this patch;
|
|
54
|
+
intentional compatibility aliases are not stale references to remove.
|
|
55
|
+
- Fix an adjacent defect when the new behavior depends on it, or isolate the
|
|
56
|
+
new path so it does not spread the defect. Record the choice. Stable pagination,
|
|
57
|
+
for example, may need an ID tiebreaker in an existing shared sort.
|
|
58
|
+
- Leave unrelated cleanup alone. A same-file edit or cheap refactor is not by
|
|
59
|
+
itself justification to expand scope. Preserve staged and unstaged user work.
|
|
60
|
+
- Record path -> responsibility -> concrete check. Include expected outputs for
|
|
61
|
+
the main path and material failure cases. Order related edits so checks remain
|
|
62
|
+
interpretable, commonly contracts -> implementation -> wiring -> tests/docs.
|
|
63
|
+
Reassess scope if the plan grows; file count alone cannot decide correctness.
|
|
64
|
+
|
|
65
|
+
Establish focused baseline results when existing failures could obscure the
|
|
66
|
+
change. Inspect shared callers before choosing wider checks; preserve exact
|
|
67
|
+
commands and results so new failures can be attributed rather than guessed.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
<!-- KIOKUKO MANAGED STANDARD SKILL: one-shot-software-completion -->
|
|
2
|
+
|
|
3
|
+
# Failure recovery
|
|
4
|
+
|
|
5
|
+
Read when a check fails or progress stalls. Recovery stays within the original
|
|
6
|
+
scope, current host role and permissions; it is not an automatic retry policy.
|
|
7
|
+
|
|
8
|
+
## Classify before editing
|
|
9
|
+
|
|
10
|
+
Read the relevant complete error and causal context. Separate observations from
|
|
11
|
+
hypotheses; multiple causes may coexist.
|
|
12
|
+
|
|
13
|
+
| Evidence indicates | Next action |
|
|
14
|
+
| --- | --- |
|
|
15
|
+
| Wrong interpretation of the requirement | Revisit the observable result and material ambiguity |
|
|
16
|
+
| Missed caller, helper contract or integration | Trace that dependency and correct the plan |
|
|
17
|
+
| Local implementation error | Apply a focused fix and its regression check |
|
|
18
|
+
| Environment/tooling failure | Verify the cause; make only an authorized, bounded repair |
|
|
19
|
+
| Failure demonstrated in the baseline | Report it; investigate if it blocks or interacts with the change |
|
|
20
|
+
|
|
21
|
+
If the same failure remains after two targeted fixes, stop making variants of
|
|
22
|
+
the same patch. Create a minimal reproduction or focused diagnostic, revisit
|
|
23
|
+
the input/contract and consider a different approach supported by repository
|
|
24
|
+
evidence. Do not rerun an unchanged failed operation without new information.
|
|
25
|
+
|
|
26
|
+
## Preserve the evidence
|
|
27
|
+
|
|
28
|
+
Do not loosen assertions, skip tests, add broad catches/casts, suppress errors
|
|
29
|
+
or increase timeouts merely to make a failure disappear. Change a check only
|
|
30
|
+
when evidence shows its expectation is wrong and explain that correction.
|
|
31
|
+
|
|
32
|
+
Fix tooling only when it blocks required verification and the repair is within
|
|
33
|
+
scope. Prefer a targeted runnable check when broader infrastructure is missing;
|
|
34
|
+
report exactly what it proves and what remains unverified. Do not rewrite CI,
|
|
35
|
+
install unrelated dependencies or change external configuration to evade a
|
|
36
|
+
blocker. A permission or credential gap is not a prompt to bypass controls.
|
|
37
|
+
|
|
38
|
+
After a repair, rerun the failed check and all checks affected by the new diff,
|
|
39
|
+
then review the final patch again. A signature repair can require caller tests,
|
|
40
|
+
typecheck and runtime integration even if only one test originally failed.
|
|
41
|
+
Stop when requirements are verified or progress requires unavailable evidence,
|
|
42
|
+
access or a consequential user decision. State the blocker and concrete next
|
|
43
|
+
action rather than claiming completion or promising unattended continuation.
|