ctxr-cli 0.13.0 → 0.15.0
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.md +12 -6
- package/dist/commands/ingest.d.ts.map +1 -1
- package/dist/commands/ingest.js +12 -1
- package/dist/commands/ingest.js.map +1 -1
- package/dist/commands/publish-gather.d.ts +3 -0
- package/dist/commands/publish-gather.d.ts.map +1 -1
- package/dist/commands/publish-gather.js +46 -3
- package/dist/commands/publish-gather.js.map +1 -1
- package/dist/config/schema.d.ts +1 -0
- package/dist/config/schema.d.ts.map +1 -1
- package/dist/config/schema.js +12 -0
- package/dist/config/schema.js.map +1 -1
- package/dist/core/checks/organize-checks.d.ts +13 -0
- package/dist/core/checks/organize-checks.d.ts.map +1 -1
- package/dist/core/checks/organize-checks.js +54 -0
- package/dist/core/checks/organize-checks.js.map +1 -1
- package/dist/core/errors.d.ts +9 -0
- package/dist/core/errors.d.ts.map +1 -1
- package/dist/core/errors.js +16 -0
- package/dist/core/errors.js.map +1 -1
- package/dist/core/ingest/required-sections.d.ts +15 -0
- package/dist/core/ingest/required-sections.d.ts.map +1 -0
- package/dist/core/ingest/required-sections.js +41 -0
- package/dist/core/ingest/required-sections.js.map +1 -0
- package/dist/core/publish/filing.d.ts +66 -0
- package/dist/core/publish/filing.d.ts.map +1 -0
- package/dist/core/publish/filing.js +147 -0
- package/dist/core/publish/filing.js.map +1 -0
- package/dist/core/skills.d.ts.map +1 -1
- package/dist/core/skills.js +15 -0
- package/dist/core/skills.js.map +1 -1
- package/dist/run.js +1 -1
- package/dist/run.js.map +1 -1
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/package.json +1 -1
- package/templates/agents/capture-and-ingest.md +4 -2
- package/templates/skills/ctxr-capture.md +61 -0
- package/templates/skills/ctxr-publish.md +36 -15
|
@@ -18,6 +18,9 @@ an unintended note slips in unnoticed:
|
|
|
18
18
|
- `--note <path>` — a single note
|
|
19
19
|
- `--entity <name>` — every note linking to a concept, the same enumeration `ctxr rollup gather` uses
|
|
20
20
|
|
|
21
|
+
It answers where the page belongs as well as what it is drawn from: the path it reports is what step
|
|
22
|
+
4 files the page at, so run it once and keep the output.
|
|
23
|
+
|
|
21
24
|
## 3. Decide what belongs on the page
|
|
22
25
|
|
|
23
26
|
The store does not decide this for you. Read the resolved set and judge, note by note, whether its
|
|
@@ -25,21 +28,39 @@ content belongs in front of this page's intended readers — a page written for
|
|
|
25
28
|
not carry material written about that party, or about anyone else who did not expect to be quoted.
|
|
26
29
|
When you are unsure about a note, leave it out and name it to the operator rather than guessing.
|
|
27
30
|
|
|
28
|
-
## 4. Fix the identity once,
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
31
|
+
## 4. Fix the identity once, at the path `gather` reported
|
|
32
|
+
|
|
33
|
+
Step 2 reported the path under the store's published-pages location at which a page for this subject
|
|
34
|
+
belongs, derived from where the subject's notes live. Take it verbatim, append the page's own name,
|
|
35
|
+
and hand the result to `ctxr publish new <slug>`, which creates the folder and its sibling README:
|
|
36
|
+
|
|
37
|
+
```sh
|
|
38
|
+
ctxr publish new <reported path>/<page-name>
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
The depth is the store's own, not a fixed number of levels — a subject whose notes live four folders
|
|
42
|
+
deep files four folders deep. That is what makes the published-pages navigation read like the store
|
|
43
|
+
instead of like one long list. `ctxr publish check` reports a page filed flat at the published-pages
|
|
44
|
+
root as a failing check, and checks nothing further about the location, because which folder is
|
|
45
|
+
right is the question `gather` already answered.
|
|
46
|
+
|
|
47
|
+
Name the page for what it *is*, never for its subject. The folders above it already carry the
|
|
48
|
+
subject, so `<reported path>/<subject>` says one word twice while `<reported path>/decision-board`
|
|
49
|
+
says something.
|
|
50
|
+
|
|
51
|
+
When `gather` reports that an existing page belongs at the reported path too, it is because this
|
|
52
|
+
subject is acquiring a second page, and a subject's pages collect under one folder naming it. Move
|
|
53
|
+
that page there before you scaffold the new one, and tell the operator its URL changed — somebody
|
|
54
|
+
may already be holding that link. `gather` moves nothing itself, and it names which signal counted
|
|
55
|
+
the page as this subject's; read that before you move anything, because the signal is a reading of
|
|
56
|
+
the page's README and can be wrong. Lead a page's source notes with the note it is a representation
|
|
57
|
+
of — that lead link is what says whose page this is, and everything after it is a citation.
|
|
58
|
+
|
|
59
|
+
When `gather` reports that no path derives — the subject names the store root itself, so no folder
|
|
60
|
+
names it — the choice is yours to make and to own: pick the folder that best names the subject to
|
|
61
|
+
the reader, write that choice and your reason into the page's README, and name it to the operator.
|
|
62
|
+
Nothing checks this for you, by design. Filing a page under a word that names nothing serves nobody
|
|
63
|
+
who reads it.
|
|
43
64
|
|
|
44
65
|
A slug starting with a date (`YYYY-` or `YYYY-MM-DD-`) is reserved for a frozen snapshot — never used
|
|
45
66
|
for a page you intend to keep updating. That rule binds the page's own final segment, not the folders
|