@panaversity/ksor 0.0.5 → 0.0.6
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
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# @panaversity/ksor
|
|
2
2
|
|
|
3
|
+
## 0.0.6
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- 3890ad2: fix: a scaffolded project has exactly two commands, one per surface —
|
|
8
|
+
`pnpm dev` for the site people read, `pnpm serve` for the record agents query
|
|
9
|
+
(it applies the schema, authorizes ingest, ingests, and serves). Neither asks
|
|
10
|
+
the reader to decide anything.
|
|
11
|
+
|
|
12
|
+
fix: the one-command script is no longer called `up`. `up` is
|
|
13
|
+
pnpm's own alias for `update`, so the script shipped in 0.0.5 was shadowed by
|
|
14
|
+
the package manager: an adopter following the runbook ran `pnpm up` expecting
|
|
15
|
+
to bring their record up and instead upgraded their dependencies. Anyone on
|
|
16
|
+
0.0.5 should use `pnpm run schema && pnpm run grant && pnpm run ingest &&
|
|
17
|
+
pnpm run serve` until they re-scaffold.
|
|
18
|
+
|
|
3
19
|
## 0.0.5
|
|
4
20
|
|
|
5
21
|
### Patch Changes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@panaversity/ksor",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.6",
|
|
4
4
|
"description": "Knowledge System of Record — the authoritative, governed source of knowledge that humans and AI agents operate from. Name reserved; implementation in progress.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"abstention",
|
|
@@ -93,28 +93,33 @@ Stand it up in this order (each step's errors explain how to fix themselves):
|
|
|
93
93
|
3. **Bring it up — one command:**
|
|
94
94
|
|
|
95
95
|
```sh
|
|
96
|
-
pnpm
|
|
96
|
+
pnpm serve # schema → grant → ingest → serve
|
|
97
97
|
```
|
|
98
98
|
|
|
99
99
|
Every step is re-runnable, so this is also how you **refresh after editing
|
|
100
100
|
`knowledge/`**: an applied schema reports "already applied", an existing
|
|
101
101
|
grant reports "already granted", and ingest builds a fresh generation.
|
|
102
102
|
|
|
103
|
-
**`pnpm
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
103
|
+
**`pnpm serve` is the only command this rung needs.** Run it the first
|
|
104
|
+
time, run it after editing `knowledge/`, run it to bring the server back —
|
|
105
|
+
it is always the right answer, so there is nothing to decide. Every step it
|
|
106
|
+
chains reports the state it found rather than failing: an applied schema
|
|
107
|
+
says "already applied", an existing grant says "already granted", and
|
|
108
|
+
unchanged chunks carry forward by content hash, so a rerun on an untouched
|
|
109
|
+
corpus makes **zero provider calls** (`embedded 0, carried N`).
|
|
110
|
+
|
|
111
|
+
What a rerun does spend is a generation — each one is created and activated,
|
|
112
|
+
and they accumulate. Reap them when you think of it, or on a schedule:
|
|
113
|
+
|
|
114
|
+
```sh
|
|
115
|
+
pnpm exec ksor gc --instance instance.md
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
The individual verbs (`pnpm schema`, `pnpm grant`, `pnpm ingest`,
|
|
119
|
+
`pnpm serve`) exist for pipelines and split duties — a deploy step that
|
|
120
|
+
ingests while a different process serves, or a DBA who holds the credentials
|
|
121
|
+
that authorize ingest. Reach for them when something else runs the steps;
|
|
122
|
+
not as a daily choice.
|
|
118
123
|
|
|
119
124
|
4. **Turn the abstention gate on — deliberately, once it serves.** This is the
|
|
120
125
|
step that makes "not in this corpus" a real answer, and it is measured, never
|
|
@@ -31,7 +31,7 @@ part of `pnpm dev`. The ordered path is:
|
|
|
31
31
|
|
|
32
32
|
```sh
|
|
33
33
|
cp .env.example .env # fill in KSOR_DB_URL, GEMINI_API_KEY, KSOR_AUTH_DISABLED=1
|
|
34
|
-
pnpm
|
|
34
|
+
pnpm serve # schema → grant → ingest → serve
|
|
35
35
|
```
|
|
36
36
|
|
|
37
37
|
`ksor` reads `.env` automatically — nothing to export. `KSOR_AUTH_DISABLED=1`
|
|
@@ -44,10 +44,9 @@ the NAME of the variable, never the DSN. That is the whole required config:
|
|
|
44
44
|
`retrieval:` out starts you with the abstention gate off and honest about it
|
|
45
45
|
(turn it on afterwards with `ksor calibrate`, once the record is serving).
|
|
46
46
|
|
|
47
|
-
`pnpm
|
|
48
|
-
`knowledge
|
|
49
|
-
untouched corpus costs no provider calls
|
|
50
|
-
building a new generation, run `pnpm serve` on its own. `AGENTS.md` → "Serving to agents" is the
|
|
47
|
+
`pnpm serve` is the only command this rung needs — first run, after editing
|
|
48
|
+
`knowledge/`, or just to bring the server back. It re-embeds only what changed,
|
|
49
|
+
so a rerun on an untouched corpus costs no provider calls. `AGENTS.md` → "Serving to agents" is the
|
|
51
50
|
full runbook; your coding agent reads it first. `pnpm serve` binds loopback
|
|
52
51
|
with auth off for local use; a public bind fails closed unless auth is
|
|
53
52
|
configured. Any other operation is `pnpm exec ksor <verb>`.
|
|
@@ -76,7 +75,7 @@ different coding agent's way of finding the same working contract.
|
|
|
76
75
|
| `.gitattributes` | markdown is checked out byte-stable on every platform, so the same commit hashes the same everywhere. |
|
|
77
76
|
| `.env.example` | the variables the served rung needs; copy to `.env` (gitignored) and fill in. |
|
|
78
77
|
| `.gitignore` | keeps build output, `node_modules/`, and `.env` out of the record's history. |
|
|
79
|
-
| `package.json` | the
|
|
78
|
+
| `package.json` | the two surface commands — `pnpm dev` (the site) and `pnpm serve` (the agent surface: schema → grant → ingest → serve) — plus `pnpm build` / `pnpm check`, the pinned `@panaversity/ksor` tool, and the pnpm version this project pins. |
|
|
80
79
|
| `pnpm-workspace.yaml` | where the workspace looks for code (`system/site`, plus reserved `system/gateways/*` and `system/packages/*`), and the supply-chain policy for installs. |
|
|
81
80
|
| `pnpm-lock.yaml` | the exact dependency versions — the reason two machines build the same site. |
|
|
82
81
|
|
|
@@ -7,11 +7,10 @@
|
|
|
7
7
|
"dev": "pnpm -C system/site dev",
|
|
8
8
|
"build": "pnpm -C system/site build",
|
|
9
9
|
"check": "node .agents/skills/format-checker/check.mjs",
|
|
10
|
-
"
|
|
10
|
+
"serve": "pnpm schema && pnpm grant && pnpm ingest && ksor serve",
|
|
11
11
|
"schema": "ksor schema --instance instance.md --apply",
|
|
12
12
|
"grant": "ksor grant --instance instance.md",
|
|
13
|
-
"ingest": "ksor ingest --instance instance.md --knowledge knowledge --flip"
|
|
14
|
-
"serve": "ksor serve"
|
|
13
|
+
"ingest": "ksor ingest --instance instance.md --knowledge knowledge --flip"
|
|
15
14
|
},
|
|
16
15
|
"dependencies": {
|
|
17
16
|
"@panaversity/ksor": "KSOR-STAMP-VERSION"
|