stego-cli 0.1.5 → 0.1.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/.gitignore +1 -0
- package/.markdownlint.manuscript.json +8 -0
- package/README.md +39 -189
- package/dist/stego-cli.js +163 -24
- package/package.json +7 -5
- package/projects/fiction-example/.markdownlint.json +5 -0
- package/projects/fiction-example/.markdownlint.manuscript.json +8 -0
- package/projects/{plague-demo → fiction-example}/README.md +5 -5
- package/projects/{plague-demo → fiction-example}/manuscript/300-the-hearing.md +1 -13
- package/projects/{plague-demo → fiction-example}/package.json +1 -1
- package/projects/{plague-demo → fiction-example}/spine/characters.md +4 -0
- package/projects/{plague-demo → fiction-example}/spine/locations.md +4 -0
- package/projects/{plague-demo → fiction-example}/spine/sources.md +3 -0
- package/projects/{plague-demo → fiction-example}/stego-project.json +1 -1
- package/projects/stego-docs/README.md +27 -0
- package/projects/stego-docs/manuscript/100-what-stego-is.md +56 -0
- package/projects/stego-docs/manuscript/200-install-and-initialize.md +68 -0
- package/projects/stego-docs/manuscript/300-workspace-layout-and-vscode.md +56 -0
- package/projects/stego-docs/manuscript/400-everyday-workflow-and-commands.md +70 -0
- package/projects/stego-docs/manuscript/500-project-configuration.md +58 -0
- package/projects/stego-docs/manuscript/600-spine-and-browser-workflows.md +55 -0
- package/projects/stego-docs/manuscript/700-validation-and-stage-gates.md +53 -0
- package/projects/stego-docs/manuscript/800-build-export-and-release-outputs.md +53 -0
- package/projects/{docs-demo → stego-docs}/package.json +1 -1
- package/projects/stego-docs/spine/commands.md +62 -0
- package/projects/stego-docs/spine/concepts.md +72 -0
- package/projects/stego-docs/spine/configuration.md +57 -0
- package/projects/stego-docs/spine/integrations.md +43 -0
- package/projects/stego-docs/spine/workflows.md +48 -0
- package/projects/stego-docs/stego-project.json +50 -0
- package/docs/conventions.md +0 -182
- package/docs/workflow.md +0 -78
- package/projects/docs-demo/README.md +0 -20
- package/projects/docs-demo/manuscript/100-what-stego-is.md +0 -37
- package/projects/docs-demo/manuscript/200-writing-workflow.md +0 -69
- package/projects/docs-demo/manuscript/300-quality-gates.md +0 -36
- package/projects/docs-demo/manuscript/400-build-and-export.md +0 -42
- package/projects/docs-demo/stego-project.json +0 -9
- package/projects/plague-demo/.markdownlint.json +0 -4
- /package/projects/{docs-demo → fiction-example}/dist/.gitkeep +0 -0
- /package/projects/{plague-demo → fiction-example}/manuscript/100-the-commission.md +0 -0
- /package/projects/{plague-demo → fiction-example}/manuscript/200-at-the-wards.md +0 -0
- /package/projects/{plague-demo → fiction-example}/manuscript/400-the-final-account.md +0 -0
- /package/projects/{plague-demo → fiction-example}/notes/style-guide.md +0 -0
- /package/projects/{plague-demo → stego-docs}/dist/.gitkeep +0 -0
- /package/projects/{docs-demo → stego-docs}/notes/implementation-notes.md +0 -0
- /package/projects/{docs-demo → stego-docs}/notes/style-guide.md +0 -0
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Under Saturn's Breath (
|
|
1
|
+
# Under Saturn's Breath (Fiction Example)
|
|
2
2
|
|
|
3
3
|
A full-configuration demo with rich metadata, three spine categories, cross-linked spine entries, and external reference links.
|
|
4
4
|
|
|
@@ -12,8 +12,8 @@ A full-configuration demo with rich metadata, three spine categories, cross-link
|
|
|
12
12
|
Run from `/Users/mattgold/Code/stego`:
|
|
13
13
|
|
|
14
14
|
```bash
|
|
15
|
-
npm run validate -- --project
|
|
16
|
-
npm run build -- --project
|
|
17
|
-
npm run check-stage -- --project
|
|
18
|
-
npm run export -- --project
|
|
15
|
+
npm run validate -- --project fiction-example
|
|
16
|
+
npm run build -- --project fiction-example
|
|
17
|
+
npm run check-stage -- --project fiction-example --stage draft
|
|
18
|
+
npm run export -- --project fiction-example --format md
|
|
19
19
|
```
|
|
@@ -23,16 +23,4 @@ No one accused him of sorcery. They accused him of carelessness: in a season of
|
|
|
23
23
|
|
|
24
24
|
He defended himself precisely. A text could be illicit in circulation yet sound in analysis; truth did not inherit legal status from its scribes. Raoul answered that governance could not afford that distinction under plague conditions.
|
|
25
25
|
|
|
26
|
-
The compromise was severe but survivable. Matthaeus would keep his position, surrender the quire, and circulate only conclusions framed in authorized language. Etienne copied the agreement and watched his master sign it without hesitation, as though the quire had already given him everything he needed and its confiscation changed nothing.
|
|
27
|
-
|
|
28
|
-
<!-- stego-comments:start -->
|
|
29
|
-
|
|
30
|
-
<!-- comment: CMT-0001 -->
|
|
31
|
-
<!-- meta64: eyJzdGF0dXMiOiJvcGVuIiwiY3JlYXRlZF9hdCI6IjIwMjYtMDItMjFUMDQ6MjI6MzguMDE4WiIsInRpbWV6b25lIjoiQW1lcmljYS9OZXdfWW9yayIsInRpbWV6b25lX29mZnNldF9taW51dGVzIjotMzAwLCJwYXJhZ3JhcGhfaW5kZXgiOjAsImV4Y2VycHRfc3RhcnRfbGluZSI6MTgsImV4Y2VycHRfc3RhcnRfY29sIjozMDcsImV4Y2VycHRfZW5kX2xpbmUiOjE4LCJleGNlcnB0X2VuZF9jb2wiOjMxM30 -->
|
|
32
|
-
> _Feb 21, 2026, 4:22 AM — mattgold_
|
|
33
|
-
>
|
|
34
|
-
> > “Arabic”
|
|
35
|
-
>
|
|
36
|
-
> spicy
|
|
37
|
-
|
|
38
|
-
<!-- stego-comments:end -->
|
|
26
|
+
The compromise was severe but survivable. Matthaeus would keep his position, surrender the quire, and circulate only conclusions framed in authorized language. Etienne copied the agreement and watched his master sign it without hesitation, as though the quire had already given him everything he needed and its confiscation changed nothing.
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
# Characters
|
|
2
2
|
|
|
3
3
|
## CHAR-MATTHAEUS
|
|
4
|
+
label: Magister Matthaeus de Rota
|
|
4
5
|
|
|
5
6
|
- Magister Matthaeus de Rota
|
|
6
7
|
- Role: Scholar of medicine and astrology at the University of Paris
|
|
@@ -9,6 +10,7 @@
|
|
|
9
10
|
- Arc: Builds a total explanation of the {{pestilence}} and dies at peace inside it; the question is whether his peace is understanding or its most sophisticated substitute
|
|
10
11
|
|
|
11
12
|
## CHAR-ETIENNE
|
|
13
|
+
label: Etienne of Saint-Marcel
|
|
12
14
|
|
|
13
15
|
- Etienne of Saint-Marcel
|
|
14
16
|
- Role: Young cleric-scribe attached to Matthaeus (CHAR-MATTHAEUS)
|
|
@@ -16,6 +18,7 @@
|
|
|
16
18
|
- Function: The story's witness; records the system without fully believing it, but also without offering an alternative
|
|
17
19
|
|
|
18
20
|
## CHAR-AGNES
|
|
21
|
+
label: Agnes the apothecary
|
|
19
22
|
|
|
20
23
|
- Agnes the apothecary
|
|
21
24
|
- Role: Compounder and practical healer near the Petit Pont; supplies Hôtel-Dieu (LOC-HOTELDIEU)
|
|
@@ -24,6 +27,7 @@
|
|
|
24
27
|
- Function: The counterweight; asks whether a system that can absorb any evidence without changing is a system or a habit
|
|
25
28
|
|
|
26
29
|
## CHAR-RAOUL
|
|
30
|
+
label: Canon Raoul de Villiers
|
|
27
31
|
|
|
28
32
|
- Canon Raoul de Villiers
|
|
29
33
|
- Role: Cathedral canon and royal intermediary overseeing the inquiry
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
# Locations
|
|
2
2
|
|
|
3
3
|
## LOC-COLLEGE
|
|
4
|
+
label: College chamber near the Rue Saint-Jacques
|
|
4
5
|
|
|
5
6
|
- College chamber near the Rue Saint-Jacques
|
|
6
7
|
- Study and disputation room
|
|
@@ -9,6 +10,7 @@
|
|
|
9
10
|
- Significance: The space where the system is built; physically separated from the wards and streets where the plague actually operates
|
|
10
11
|
|
|
11
12
|
## LOC-HOTELDIEU
|
|
13
|
+
label: "Hôtel-Dieu"
|
|
12
14
|
|
|
13
15
|
- Hôtel-Dieu
|
|
14
16
|
- Hospital ward near Notre-Dame
|
|
@@ -17,6 +19,7 @@
|
|
|
17
19
|
- Significance: Where data is collected; the distance between this room and the college chamber is the distance between observation and explanation
|
|
18
20
|
|
|
19
21
|
## LOC-QUAY
|
|
22
|
+
label: Grain quay on the Seine
|
|
20
23
|
|
|
21
24
|
- Grain quay on the Seine
|
|
22
25
|
- River unloading zone
|
|
@@ -25,6 +28,7 @@
|
|
|
25
28
|
- Significance: Agnes's observations (SRC-WARD-DATA) trace infection along this route; it is the strongest evidence for material transmission and the hardest for the celestial framework (SRC-CONJUNCTION) to accommodate
|
|
26
29
|
|
|
27
30
|
## LOC-CHARNEL
|
|
31
|
+
label: Charnel precinct at the cemetery edge
|
|
28
32
|
|
|
29
33
|
- Charnel precinct at the cemetery edge
|
|
30
34
|
- Overflow burial ground
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
# Sources
|
|
2
2
|
|
|
3
3
|
## SRC-CONJUNCTION
|
|
4
|
+
label: The Great Conjunction theory
|
|
4
5
|
|
|
5
6
|
- The Great Conjunction theory
|
|
6
7
|
- Tradition: University astrology ([Paris faculty opinion of 1348](https://en.wikipedia.org/wiki/Black_Death#Medical_knowledge))
|
|
@@ -10,6 +11,7 @@
|
|
|
10
11
|
- Limitation: Explains everything at once, which means it predicts nothing in particular
|
|
11
12
|
|
|
12
13
|
## SRC-GALEN
|
|
14
|
+
label: Galenic humoral medicine
|
|
13
15
|
|
|
14
16
|
- Galenic humoral medicine
|
|
15
17
|
- Tradition: Greco-Arabic medical inheritance
|
|
@@ -19,6 +21,7 @@
|
|
|
19
21
|
- Limitation: Cannot explain why entire neighborhoods fall at once regardless of individual constitution
|
|
20
22
|
|
|
21
23
|
## SRC-WARD-DATA
|
|
24
|
+
label: "Agnes's ward observations"
|
|
22
25
|
|
|
23
26
|
- Agnes's ward observations
|
|
24
27
|
- Tradition: None; empirical record-keeping without institutional backing
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Stego Docs
|
|
2
|
+
|
|
3
|
+
This is the canonical Stego documentation project.
|
|
4
|
+
|
|
5
|
+
It is a real Stego project that demonstrates:
|
|
6
|
+
|
|
7
|
+
- docs-first usage of the workspace model
|
|
8
|
+
- Spine-driven navigation for commands, concepts, workflows, configuration, and integrations
|
|
9
|
+
- build/export behavior for documentation teams
|
|
10
|
+
|
|
11
|
+
## Read the docs
|
|
12
|
+
|
|
13
|
+
Open `manuscript/` in order, or build the compiled manual:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
stego build --project stego-docs
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
If you are working in this source repo (not a scaffolded workspace), the equivalent is:
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
npm run build -- --project stego-docs
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Recommended VS Code workflow
|
|
26
|
+
|
|
27
|
+
Open `projects/stego-docs` directly in VS Code while editing this project so project recommendations and the Spine Browser stay focused on the documentation graph.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 1
|
|
4
|
+
chapter_title: What Stego Is
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-WORKSPACE
|
|
7
|
+
- CON-PROJECT
|
|
8
|
+
- CON-MANUSCRIPT
|
|
9
|
+
- CON-NOTES
|
|
10
|
+
- CON-DIST
|
|
11
|
+
workflows:
|
|
12
|
+
- FLOW-INIT-WORKSPACE
|
|
13
|
+
- FLOW-DAILY-WRITING
|
|
14
|
+
commands:
|
|
15
|
+
- CMD-INIT
|
|
16
|
+
- CMD-LIST-PROJECTS
|
|
17
|
+
integrations:
|
|
18
|
+
- INT-VSCODE
|
|
19
|
+
- INT-STEGO-EXTENSION
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# What Stego Is
|
|
23
|
+
|
|
24
|
+
Stego is a Markdown-first writing workflow organized around a workspace that contains one or more writing projects.
|
|
25
|
+
|
|
26
|
+
It combines local source files, validation, stage gates, build output, and export into a single CLI-driven system that works well with Git and VS Code.
|
|
27
|
+
|
|
28
|
+
The CLI is the command and automation surface, and the Stego VS Code extension is the official UI for working inside Stego projects.
|
|
29
|
+
|
|
30
|
+
## Core model
|
|
31
|
+
|
|
32
|
+
A Stego workspace has a shared root configuration and a `projects/` directory.
|
|
33
|
+
|
|
34
|
+
Each project is self-contained and typically includes:
|
|
35
|
+
|
|
36
|
+
- `manuscript/` for canonical source text
|
|
37
|
+
- `notes/` for planning and reference material
|
|
38
|
+
- `spine/` for canonical entities and reference graphs (when enabled)
|
|
39
|
+
- `dist/` for generated output only
|
|
40
|
+
|
|
41
|
+
## Why this structure works
|
|
42
|
+
|
|
43
|
+
Stego keeps source authoring close to the tools that evaluate and build it.
|
|
44
|
+
|
|
45
|
+
That makes it easier to:
|
|
46
|
+
|
|
47
|
+
- validate metadata and structure early
|
|
48
|
+
- run stage-aware checks before release milestones
|
|
49
|
+
- build deterministic compiled output for review
|
|
50
|
+
- keep generated artifacts separate from hand-edited source material
|
|
51
|
+
|
|
52
|
+
## Who this is for
|
|
53
|
+
|
|
54
|
+
Stego works for fiction, nonfiction, and internal documentation teams.
|
|
55
|
+
|
|
56
|
+
This project (`stego-docs`) demonstrates the documentation use case. The parent workspace includes a `fiction-example` as well.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 2
|
|
4
|
+
chapter_title: Install and Initialize
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-WORKSPACE
|
|
7
|
+
- CON-PROJECT
|
|
8
|
+
commands:
|
|
9
|
+
- CMD-INIT
|
|
10
|
+
- CMD-LIST-PROJECTS
|
|
11
|
+
workflows:
|
|
12
|
+
- FLOW-INIT-WORKSPACE
|
|
13
|
+
integrations:
|
|
14
|
+
- INT-VSCODE
|
|
15
|
+
- INT-STEGO-EXTENSION
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# Install and Initialize
|
|
19
|
+
|
|
20
|
+
## Install the CLI
|
|
21
|
+
|
|
22
|
+
Install the CLI globally so the `stego` command is available in your shell.
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
npm install -g stego-cli
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Create a workspace
|
|
29
|
+
|
|
30
|
+
Start in an empty directory and initialize a Stego workspace.
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
mkdir my-stego-workspace
|
|
34
|
+
cd my-stego-workspace
|
|
35
|
+
stego init
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
The command scaffolds a workspace with a root config, root scripts, VS Code tasks, and two example projects: `stego-docs` and `fiction-example`.
|
|
39
|
+
|
|
40
|
+
If you need to initialize into a non-empty directory, run `stego init --force`.
|
|
41
|
+
|
|
42
|
+
## Install workspace tools
|
|
43
|
+
|
|
44
|
+
After scaffolding, install the workspace dependencies used by local scripts and quality checks.
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
npm install
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## Open a project in the official UI
|
|
51
|
+
|
|
52
|
+
After scaffolding, open one project directory in VS Code (start with `projects/stego-docs`).
|
|
53
|
+
|
|
54
|
+
The Stego VS Code extension is the official UI for Stego projects. It provides project-aware controls, checks, and Spine Browser navigation while you edit.
|
|
55
|
+
|
|
56
|
+
The scaffolded project folders include extension recommendations to help you install the Stego extension (and the Saurus companion extension) quickly.
|
|
57
|
+
|
|
58
|
+
## Confirm the workspace is working
|
|
59
|
+
|
|
60
|
+
Run a few commands from the workspace root.
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
stego list-projects
|
|
64
|
+
stego validate --project stego-docs
|
|
65
|
+
stego build --project stego-docs
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
The full documentation for the workspace lives inside the `stego-docs` project you just scaffolded.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 3
|
|
4
|
+
chapter_title: Workspace Layout and VS Code
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-WORKSPACE
|
|
7
|
+
- CON-PROJECT
|
|
8
|
+
- CON-MANUSCRIPT
|
|
9
|
+
- CON-NOTES
|
|
10
|
+
- CON-SPINE
|
|
11
|
+
- CON-DIST
|
|
12
|
+
commands:
|
|
13
|
+
- CMD-INIT
|
|
14
|
+
- CMD-NEW-PROJECT
|
|
15
|
+
workflows:
|
|
16
|
+
- FLOW-INIT-WORKSPACE
|
|
17
|
+
- FLOW-NEW-PROJECT
|
|
18
|
+
integrations:
|
|
19
|
+
- INT-VSCODE
|
|
20
|
+
- INT-STEGO-EXTENSION
|
|
21
|
+
- INT-SAURUS-EXTENSION
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
# Workspace Layout and VS Code
|
|
25
|
+
|
|
26
|
+
## Workspace-level files
|
|
27
|
+
|
|
28
|
+
At the workspace root you will typically see:
|
|
29
|
+
|
|
30
|
+
- `stego.config.json` for shared configuration and stage policies
|
|
31
|
+
- `projects/` for all writing projects
|
|
32
|
+
- `.vscode/tasks.json` for common root tasks
|
|
33
|
+
- `package.json` for root scripts and tool dependencies
|
|
34
|
+
|
|
35
|
+
## Project layout
|
|
36
|
+
|
|
37
|
+
Each project under `projects/<project-id>/` contains its own source and configuration.
|
|
38
|
+
|
|
39
|
+
Typical folders:
|
|
40
|
+
|
|
41
|
+
- `manuscript/` for ordered source chapters or sections
|
|
42
|
+
- `notes/` for planning and references
|
|
43
|
+
- `spine/` for canonical entities (when a project enables Spine categories)
|
|
44
|
+
- `dist/` for generated outputs
|
|
45
|
+
|
|
46
|
+
## Recommended VS Code workflow
|
|
47
|
+
|
|
48
|
+
When actively working on one project, open that project directory directly in VS Code instead of the whole workspace.
|
|
49
|
+
|
|
50
|
+
That keeps editor context focused and ensures project recommendations apply at the project level.
|
|
51
|
+
|
|
52
|
+
## Prose-style editor settings prompt
|
|
53
|
+
|
|
54
|
+
When you run `stego init` or `stego new-project`, Stego can optionally write project-level markdown editor settings for a prose-friendly font and layout.
|
|
55
|
+
|
|
56
|
+
Those settings are written to the project folder only, not the workspace root, so different projects can use different editor preferences.
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 4
|
|
4
|
+
chapter_title: Everyday Workflow and Commands
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-PROJECT
|
|
7
|
+
- CON-MANUSCRIPT
|
|
8
|
+
- CON-METADATA
|
|
9
|
+
- CON-DIST
|
|
10
|
+
commands:
|
|
11
|
+
- CMD-LIST-PROJECTS
|
|
12
|
+
- CMD-NEW-PROJECT
|
|
13
|
+
- CMD-VALIDATE
|
|
14
|
+
- CMD-BUILD
|
|
15
|
+
- CMD-CHECK-STAGE
|
|
16
|
+
- CMD-EXPORT
|
|
17
|
+
workflows:
|
|
18
|
+
- FLOW-DAILY-WRITING
|
|
19
|
+
- FLOW-NEW-PROJECT
|
|
20
|
+
- FLOW-BUILD-EXPORT
|
|
21
|
+
integrations:
|
|
22
|
+
- INT-VSCODE
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# Everyday Workflow and Commands
|
|
26
|
+
|
|
27
|
+
## Daily loop
|
|
28
|
+
|
|
29
|
+
A practical Stego writing loop looks like this:
|
|
30
|
+
|
|
31
|
+
1. Open one project folder in VS Code.
|
|
32
|
+
2. Write or revise files in `manuscript/`.
|
|
33
|
+
3. Run `stego validate` for fast structural feedback.
|
|
34
|
+
4. Run `stego build` to inspect the compiled output.
|
|
35
|
+
5. Run `stego check-stage` before moving to the next editorial milestone.
|
|
36
|
+
6. Export formats as needed for review or delivery.
|
|
37
|
+
|
|
38
|
+
## Root-level command usage
|
|
39
|
+
|
|
40
|
+
From the workspace root, target a project with `--project`.
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
stego list-projects
|
|
44
|
+
stego validate --project fiction-example
|
|
45
|
+
stego build --project fiction-example
|
|
46
|
+
stego check-stage --project fiction-example --stage revise
|
|
47
|
+
stego export --project fiction-example --format md
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## Project-local scripts
|
|
51
|
+
|
|
52
|
+
Projects also include local npm scripts. These are useful when you want to stay in one project directory.
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
cd projects/fiction-example
|
|
56
|
+
npm run validate
|
|
57
|
+
npm run build
|
|
58
|
+
npm run check-stage -- --stage revise
|
|
59
|
+
npm run export -- --format md
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
## Create a new project
|
|
63
|
+
|
|
64
|
+
Use `stego new-project` from the workspace root.
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
stego new-project --project my-book --title "My Book"
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
This scaffolds manuscript, notes, spine, and dist folders, a project config, local scripts, extension recommendations, and (optionally) project-level prose editor settings.
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 5
|
|
4
|
+
chapter_title: Project Configuration
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-WORKSPACE
|
|
7
|
+
- CON-PROJECT
|
|
8
|
+
- CON-METADATA
|
|
9
|
+
- CON-COMPILE-STRUCTURE
|
|
10
|
+
- CON-SPINE
|
|
11
|
+
- CON-SPINE-CATEGORY
|
|
12
|
+
commands:
|
|
13
|
+
- CMD-VALIDATE
|
|
14
|
+
- CMD-BUILD
|
|
15
|
+
workflows:
|
|
16
|
+
- FLOW-NEW-PROJECT
|
|
17
|
+
- FLOW-DAILY-WRITING
|
|
18
|
+
configuration:
|
|
19
|
+
- CFG-STEGO-CONFIG
|
|
20
|
+
- CFG-STEGO-PROJECT
|
|
21
|
+
- CFG-REQUIRED-METADATA
|
|
22
|
+
- CFG-COMPILE-STRUCTURE
|
|
23
|
+
- CFG-COMPILE-LEVELS
|
|
24
|
+
- CFG-SPINE-CATEGORIES
|
|
25
|
+
- CFG-STAGE-POLICIES
|
|
26
|
+
- CFG-ALLOWED-STATUSES
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
# Project Configuration
|
|
30
|
+
|
|
31
|
+
Stego uses two configuration layers:
|
|
32
|
+
|
|
33
|
+
- `stego.config.json` at the workspace root for shared directories and stage policies
|
|
34
|
+
- `stego-project.json` inside each project for project-specific rules
|
|
35
|
+
|
|
36
|
+
## Metadata requirements
|
|
37
|
+
|
|
38
|
+
Projects can declare advisory metadata keys in `requiredMetadata`.
|
|
39
|
+
|
|
40
|
+
Stego reports missing keys as warnings so teams can standardize frontmatter without blocking early drafting.
|
|
41
|
+
|
|
42
|
+
Common keys include `status`, grouping fields such as `chapter`, and project-specific metadata such as point of view or timeline.
|
|
43
|
+
|
|
44
|
+
## Compile structure
|
|
45
|
+
|
|
46
|
+
Projects can define `compileStructure.levels` to group manuscript files during build.
|
|
47
|
+
|
|
48
|
+
This is how Stego inserts structural headings and optional page breaks while still letting authors keep source files small and file-first.
|
|
49
|
+
|
|
50
|
+
Grouping metadata can be repeated at boundaries only, because Stego inherits missing group values and titles from earlier files in order.
|
|
51
|
+
|
|
52
|
+
## Spine categories
|
|
53
|
+
|
|
54
|
+
Projects that use continuity tracking or concept browsing define `spineCategories` in `stego-project.json`.
|
|
55
|
+
|
|
56
|
+
Each category maps a metadata key to an ID prefix and a canonical notes file in `spine/`.
|
|
57
|
+
|
|
58
|
+
This project uses Spine categories to model documentation entities such as commands, concepts, workflows, configuration topics, and integrations.
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 6
|
|
4
|
+
chapter_title: Spine and Browser Workflows
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-SPINE
|
|
7
|
+
- CON-SPINE-CATEGORY
|
|
8
|
+
- CON-METADATA
|
|
9
|
+
- CON-PROJECT
|
|
10
|
+
commands:
|
|
11
|
+
- CMD-VALIDATE
|
|
12
|
+
workflows:
|
|
13
|
+
- FLOW-DAILY-WRITING
|
|
14
|
+
- FLOW-STAGE-PROMOTION
|
|
15
|
+
configuration:
|
|
16
|
+
- CFG-SPINE-CATEGORIES
|
|
17
|
+
integrations:
|
|
18
|
+
- INT-STEGO-EXTENSION
|
|
19
|
+
- INT-VSCODE
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# Spine and Browser Workflows
|
|
23
|
+
|
|
24
|
+
Stego's Spine model is useful beyond fiction. In this project, Spine acts as a canonical graph for documentation topics.
|
|
25
|
+
|
|
26
|
+
## How `stego-docs` uses Spine
|
|
27
|
+
|
|
28
|
+
The documentation project defines categories for:
|
|
29
|
+
|
|
30
|
+
- commands
|
|
31
|
+
- concepts
|
|
32
|
+
- workflows
|
|
33
|
+
- configuration topics
|
|
34
|
+
- integrations
|
|
35
|
+
|
|
36
|
+
Each manuscript chapter references relevant entries in frontmatter metadata. That lets the Stego extension's Spine Browser act as an alternate way to explore the docs.
|
|
37
|
+
|
|
38
|
+
## Why this is useful for documentation teams
|
|
39
|
+
|
|
40
|
+
Using Spine in docs gives you:
|
|
41
|
+
|
|
42
|
+
- a canonical glossary with relationships
|
|
43
|
+
- a browseable map of commands and workflows
|
|
44
|
+
- traceability from a chapter to the concepts it depends on
|
|
45
|
+
- a reusable pattern for internal process documentation
|
|
46
|
+
|
|
47
|
+
## Fiction workflows still use the same model
|
|
48
|
+
|
|
49
|
+
The `fiction-example` project shows the same mechanism applied to story continuity with entities such as characters, locations, and sources.
|
|
50
|
+
|
|
51
|
+
That makes `stego-docs` a good bridge project: it documents the feature while demonstrating a non-fiction use case for the same structure.
|
|
52
|
+
|
|
53
|
+
## Extension workflow
|
|
54
|
+
|
|
55
|
+
When working in VS Code with the Stego extension, open the project folder and use the Spine Browser to inspect categories, entries, and cross-links while editing chapters.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 7
|
|
4
|
+
chapter_title: Validation and Stage Gates
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-METADATA
|
|
7
|
+
- CON-STAGE-GATE
|
|
8
|
+
- CON-SPINE
|
|
9
|
+
commands:
|
|
10
|
+
- CMD-VALIDATE
|
|
11
|
+
- CMD-CHECK-STAGE
|
|
12
|
+
workflows:
|
|
13
|
+
- FLOW-STAGE-PROMOTION
|
|
14
|
+
- FLOW-PROOF-RELEASE
|
|
15
|
+
configuration:
|
|
16
|
+
- CFG-REQUIRED-METADATA
|
|
17
|
+
- CFG-STAGE-POLICIES
|
|
18
|
+
- CFG-ALLOWED-STATUSES
|
|
19
|
+
integrations:
|
|
20
|
+
- INT-MARKDOWNLINT
|
|
21
|
+
- INT-CSPELL
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
# Validation and Stage Gates
|
|
25
|
+
|
|
26
|
+
Stego separates baseline validation from stage-aware enforcement.
|
|
27
|
+
|
|
28
|
+
## `validate`
|
|
29
|
+
|
|
30
|
+
Use `validate` for fast project integrity checks while drafting or restructuring.
|
|
31
|
+
|
|
32
|
+
It checks configuration shape, manuscript ordering, metadata parsing, and continuity reference structure.
|
|
33
|
+
|
|
34
|
+
## `check-stage`
|
|
35
|
+
|
|
36
|
+
Use `check-stage` to ask whether a file or project is ready for a specific editorial stage.
|
|
37
|
+
|
|
38
|
+
Stages typically progress from draft through revise, line edit, proof, and final. Higher stages enable stricter policies.
|
|
39
|
+
|
|
40
|
+
## Blocking vs advisory checks
|
|
41
|
+
|
|
42
|
+
Stego reports a mix of errors and warnings:
|
|
43
|
+
|
|
44
|
+
- errors block the command result
|
|
45
|
+
- warnings highlight issues worth fixing but do not stop work
|
|
46
|
+
|
|
47
|
+
This lets teams keep early drafting fast while tightening quality standards later in the workflow.
|
|
48
|
+
|
|
49
|
+
## Proof and final expectations
|
|
50
|
+
|
|
51
|
+
Proof and final stages commonly enable stricter checks such as markdown linting, spelling checks, local link validation, and resolved comment requirements.
|
|
52
|
+
|
|
53
|
+
Those rules are configured in stage policies at the workspace level.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
status: draft
|
|
3
|
+
chapter: 8
|
|
4
|
+
chapter_title: Build, Export, and Release Outputs
|
|
5
|
+
concepts:
|
|
6
|
+
- CON-MANUSCRIPT
|
|
7
|
+
- CON-DIST
|
|
8
|
+
- CON-COMPILE-STRUCTURE
|
|
9
|
+
- CON-STAGE-GATE
|
|
10
|
+
commands:
|
|
11
|
+
- CMD-BUILD
|
|
12
|
+
- CMD-EXPORT
|
|
13
|
+
- CMD-CHECK-STAGE
|
|
14
|
+
workflows:
|
|
15
|
+
- FLOW-BUILD-EXPORT
|
|
16
|
+
- FLOW-PROOF-RELEASE
|
|
17
|
+
configuration:
|
|
18
|
+
- CFG-COMPILE-STRUCTURE
|
|
19
|
+
integrations:
|
|
20
|
+
- INT-PANDOC
|
|
21
|
+
- INT-MARKDOWNLINT
|
|
22
|
+
- INT-CSPELL
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# Build, Export, and Release Outputs
|
|
26
|
+
|
|
27
|
+
## Build contract
|
|
28
|
+
|
|
29
|
+
`stego build` compiles one project's manuscript files into a single markdown output in `dist/`.
|
|
30
|
+
|
|
31
|
+
The build is deterministic because source ordering comes from filename prefixes and grouping behavior comes from project configuration.
|
|
32
|
+
|
|
33
|
+
Generated files in `dist/` should not be hand-edited.
|
|
34
|
+
|
|
35
|
+
## Export formats
|
|
36
|
+
|
|
37
|
+
`stego export` supports markdown output directly and optional richer formats through Pandoc, including docx, pdf, and epub.
|
|
38
|
+
|
|
39
|
+
If you export pdf through Pandoc, you also need a compatible PDF engine installed on your machine.
|
|
40
|
+
|
|
41
|
+
## Recommended release sequence
|
|
42
|
+
|
|
43
|
+
1. Run `stego validate` during drafting and revision.
|
|
44
|
+
2. Run `stego check-stage` for the intended milestone.
|
|
45
|
+
3. Run `stego build` to produce the compiled manuscript.
|
|
46
|
+
4. Run `stego export` for the delivery format.
|
|
47
|
+
5. Archive exported artifacts from `dist/exports` as release outputs.
|
|
48
|
+
|
|
49
|
+
## Reproducibility rule
|
|
50
|
+
|
|
51
|
+
Treat `manuscript/`, `notes/`, and `spine/` as source of truth.
|
|
52
|
+
|
|
53
|
+
Treat `dist/` as reproducible output that can be rebuilt at any time.
|