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.
Files changed (39) hide show
  1. package/README.md +12 -6
  2. package/dist/commands/ingest.d.ts.map +1 -1
  3. package/dist/commands/ingest.js +12 -1
  4. package/dist/commands/ingest.js.map +1 -1
  5. package/dist/commands/publish-gather.d.ts +3 -0
  6. package/dist/commands/publish-gather.d.ts.map +1 -1
  7. package/dist/commands/publish-gather.js +46 -3
  8. package/dist/commands/publish-gather.js.map +1 -1
  9. package/dist/config/schema.d.ts +1 -0
  10. package/dist/config/schema.d.ts.map +1 -1
  11. package/dist/config/schema.js +12 -0
  12. package/dist/config/schema.js.map +1 -1
  13. package/dist/core/checks/organize-checks.d.ts +13 -0
  14. package/dist/core/checks/organize-checks.d.ts.map +1 -1
  15. package/dist/core/checks/organize-checks.js +54 -0
  16. package/dist/core/checks/organize-checks.js.map +1 -1
  17. package/dist/core/errors.d.ts +9 -0
  18. package/dist/core/errors.d.ts.map +1 -1
  19. package/dist/core/errors.js +16 -0
  20. package/dist/core/errors.js.map +1 -1
  21. package/dist/core/ingest/required-sections.d.ts +15 -0
  22. package/dist/core/ingest/required-sections.d.ts.map +1 -0
  23. package/dist/core/ingest/required-sections.js +41 -0
  24. package/dist/core/ingest/required-sections.js.map +1 -0
  25. package/dist/core/publish/filing.d.ts +66 -0
  26. package/dist/core/publish/filing.d.ts.map +1 -0
  27. package/dist/core/publish/filing.js +147 -0
  28. package/dist/core/publish/filing.js.map +1 -0
  29. package/dist/core/skills.d.ts.map +1 -1
  30. package/dist/core/skills.js +15 -0
  31. package/dist/core/skills.js.map +1 -1
  32. package/dist/run.js +1 -1
  33. package/dist/run.js.map +1 -1
  34. package/dist/version.d.ts +1 -1
  35. package/dist/version.js +1 -1
  36. package/package.json +1 -1
  37. package/templates/agents/capture-and-ingest.md +4 -2
  38. package/templates/skills/ctxr-capture.md +61 -0
  39. 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, and file it where its subject lives
29
-
30
- `ctxr publish new <slug>` creates the page's folder. The slug is a path, and its shape carries
31
- meaning: file the page under the top-level folder its subject's notes live in, and name it for the
32
- subject — `<top-level-folder>/<subject>`, never `<subject>` alone at the root. Two levels, no more:
33
- the first says where in the store this belongs, the second says what it is. That is what makes the
34
- published-pages navigation read like the store instead of like one long list, and
35
- `ctxr publish check` reports a page filed flat at the publish root as a failing check.
36
-
37
- When the notes step 2 gathered span more than one top-level folder — or the store's taxonomy declares
38
- none at all — no folder is derivable and the choice is yours to make and to own: pick the one that
39
- best names the subject to the reader, write that choice and your reason into the page's README, and
40
- name it to the operator. Nothing checks this for you, by design. A page whose sources aren't
41
- co-located is exactly the kind step 1 says most earns a page, and filing it under a word that names
42
- nothing serves nobody who reads it.
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