genesis-compiler 1.10.21 → 1.10.23
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 +37 -7
- package/docs/prompt-integration.md +13 -2
- package/docs/stack-components.md +1 -1
- package/package.json +6 -2
- package/plugins/genesis/.codex-plugin/plugin.json +1 -1
- package/prompts/master-pass.txt +17 -0
- package/prompts/pass-deep.txt +77 -0
- package/prompts/pass-report.txt +15 -0
- package/prompts/review.txt +2 -1
- package/skills/genesis-data-pass/SKILL.md +24 -7
- package/skills/genesis-deslop/SKILL.md +25 -3
- package/skills/genesis-identity-pass/SKILL.md +20 -3
- package/skills/genesis-master-pass/SKILL.md +132 -0
- package/skills/genesis-master-pass/agents/openai.yaml +4 -0
- package/skills/genesis-project/references/sanity-checks.md +53 -12
- package/skills/genesis-quality-pass/SKILL.md +21 -3
- package/skills/genesis-review/SKILL.md +120 -0
- package/skills/genesis-review/agents/openai.yaml +4 -0
- package/skills/genesis-security-pass/SKILL.md +21 -3
- package/skills/genesis-speed-pass/SKILL.md +21 -3
- package/skills/genesis-ui-pass/SKILL.md +21 -3
- package/skills/genesis-ux-pass/SKILL.md +20 -3
- package/src/cli-commands.js +3 -1
- package/src/cli.js +12 -4
- package/src/index/agent-skills.js +4 -3
- package/src/index/assets.js +4 -1
- package/src/index/code-index.js +2 -1
- package/src/index/contracts.js +1 -0
- package/src/index/master-pass.js +76 -0
- package/src/index/pass-record.js +101 -24
- package/src/index/pass-support.js +4 -1
- package/src/index/passes.js +55 -1
- package/src/index/project-files.js +2 -1
- package/src/index/prompt.js +221 -37
- package/src/index/source-size.js +62 -0
- package/src/index.js +5 -1
package/README.md
CHANGED
|
@@ -29,7 +29,8 @@ genesis/
|
|
|
29
29
|
stack.md selected components, resources, verification, and project-owned operation contracts
|
|
30
30
|
stack/ optional per-component Description, Guidance, Adoption, Post-change, and pass customization
|
|
31
31
|
subsystems.md authored responsibilities, Program membership, and data ownership/use
|
|
32
|
-
passes.json when each pass last finished, written by its last step (absent until one does)
|
|
32
|
+
passes.json when each pass Genesis 1.10.21 knew last finished, written by its last step (absent until one does)
|
|
33
|
+
passes-added.json the same for every pass added since, such as the review and the Master pass
|
|
33
34
|
program/ concise public-operation explanations
|
|
34
35
|
.agents/skills/
|
|
35
36
|
genesis-* Genesis workflow skills
|
|
@@ -188,11 +189,11 @@ type a command. It never runs adoption without approval and does nothing in an
|
|
|
188
189
|
empty or already-adopted project.
|
|
189
190
|
|
|
190
191
|
`genesis init` creates an empty Blueprint, a focused engineering approach, an
|
|
191
|
-
empty optional Stack, the current `genesis/version`,
|
|
192
|
+
empty optional Stack, the current `genesis/version`, twelve project Agent Skills,
|
|
192
193
|
and project-local guidance adapters for Codex, Claude Code and OpenCode. The skills are ordinary
|
|
193
194
|
[Agent Skills](https://agentskills.io): `genesis-project`, `genesis-program`,
|
|
194
195
|
and one for each pass (`genesis-deslop`, `genesis-ui-pass`, `genesis-identity-pass`,
|
|
195
|
-
`genesis-quality-pass`, `genesis-data-pass`, `genesis-security-pass`, `genesis-ux-pass
|
|
196
|
+
`genesis-quality-pass`, `genesis-data-pass`, `genesis-security-pass`, `genesis-ux-pass`, `genesis-speed-pass` and `genesis-review`), and `genesis-master-pass`, which runs them deeply in turn, each with standard `SKILL.md` and
|
|
196
197
|
`agents/openai.yaml` metadata. Open `/hooks` once in Codex to review and trust the guidance hook;
|
|
197
198
|
Claude Code loads its project hooks and OpenCode discovers its local project plugin automatically. All three use the same
|
|
198
199
|
Genesis-owned operating guide for new sessions and after compaction. When the
|
|
@@ -256,7 +257,8 @@ files alone does not refresh its existing context.
|
|
|
256
257
|
| `genesis stack list` | Lists technology components from the installed Stack catalog. |
|
|
257
258
|
| `genesis stack add <piece...>` | Resolves component dependencies/conflicts, records the selection, materializes missing project contracts, synchronizes declared skills, and prints the one-time preparation prompt. It does not install application packages or run an agent. |
|
|
258
259
|
| `genesis skills sync` | Refreshes selected, unmodified managed skills while preserving customized and unmanaged copies. |
|
|
259
|
-
| `genesis passes done <pass>` | Records in `genesis/passes.json`
|
|
260
|
+
| `genesis passes done <pass>` | Records that a pass finished now, in `genesis/passes.json` or, for a pass added since Genesis 1.10.21, `genesis/passes-added.json`; every pass run's prompt ends with it. |
|
|
261
|
+
| `genesis passes done master-pass <pass...>` | Records that a Master pass finished now, with the passes it ran; its prompt ends with it. |
|
|
260
262
|
| `genesis context <path...>` | Returns path-focused Program explanations, indexed functions, selected technology guidance, exact project contracts, and relevant skills. |
|
|
261
263
|
| `genesis index [--call-web] [function-or-path...]` | Regenerates the derived code indexes and optionally searches the existing function/method inventory. `--call-web` also writes the derived function call web. |
|
|
262
264
|
| `genesis inspect environment` | Reports declared resources, public defaults, missing input names, and environment-file paths without returning secret values. |
|
|
@@ -641,8 +643,9 @@ pixels in light and dark are the evidence. See [docs/ui-pass.md](docs/ui-pass.md
|
|
|
641
643
|
|
|
642
644
|
Six more passes run only when asked, over the whole app unless the request
|
|
643
645
|
names a section or your changes. Every pass, Deslop and the UI pass included,
|
|
644
|
-
runs as a pass over the whole app,
|
|
645
|
-
|
|
646
|
+
runs as a pass over the whole app, over the changes since its last completed
|
|
647
|
+
run judged against the whole app, or deeply over the whole app, item by item,
|
|
648
|
+
and only those runs are recorded:
|
|
646
649
|
|
|
647
650
|
```text
|
|
648
651
|
Give the app its visual identity
|
|
@@ -685,11 +688,38 @@ sanity checks guide; selected Stack components add where each piece lives in
|
|
|
685
688
|
their technology. `genesis inspect passes` lists every pass, Deslop and the UI
|
|
686
689
|
pass included, for a host to offer, with when each last finished and the runs
|
|
687
690
|
it offers, each with the request to send: a pass run's last step, `genesis
|
|
688
|
-
passes done <pass>`, records that in the committed `genesis/passes.json
|
|
691
|
+
passes done <pass>`, records that in the committed `genesis/passes.json` (for a
|
|
692
|
+
pass added since Genesis 1.10.21, `genesis/passes-added.json`). A
|
|
689
693
|
project pinned to an older `genesis-compiler` gets only the passes its own
|
|
690
694
|
release runs; the others say which update adds them. See
|
|
691
695
|
[docs/passes.md](docs/passes.md).
|
|
692
696
|
|
|
697
|
+
A deep run, such as `Security pass the whole app deeply.`, first writes a
|
|
698
|
+
checklist of every file of the project's own source plus what the pass's lens
|
|
699
|
+
adds (every way in for the security pass, every screen for the UI pass), then
|
|
700
|
+
ticks each item only with evidence a reader can check: a named test in the
|
|
701
|
+
final whole-suite run, a kept measurement or output, a commit, or a command and
|
|
702
|
+
the refusal it saw. It splits the work by subsystem across several agents where
|
|
703
|
+
the host can run them, commits its own work in small steps, and opens its report
|
|
704
|
+
with the count of items ticked. `genesis inspect passes` shows its size, the
|
|
705
|
+
files and lines its checklist starts from. Every pass report, deep or not, says
|
|
706
|
+
what it read in full and what it only searched.
|
|
707
|
+
|
|
708
|
+
A Master pass runs every pass deeply, one after another, or only the passes
|
|
709
|
+
named, such as `Master pass (security, data, deslop) the whole app.`, always in
|
|
710
|
+
one order: review, security, data, quality, speed, user experience, visual
|
|
711
|
+
identity, UI and Deslop. Each pass is its own Deep run from its own prompt, and is committed
|
|
712
|
+
with the whole test suite passing before the next starts; a ledger lets an
|
|
713
|
+
interrupted Master pass continue, and one combined report covers every pass.
|
|
714
|
+
Once a Master pass is committed, it also runs over the changes since it: each
|
|
715
|
+
pass checks every changed file, the code those changes call or replace, and the
|
|
716
|
+
whole app for what they duplicate or leave dead.
|
|
717
|
+
|
|
718
|
+
```bash
|
|
719
|
+
genesis prompt --task master-pass
|
|
720
|
+
genesis prompt --task master-pass "Master pass (security, data, deslop) the whole app."
|
|
721
|
+
```
|
|
722
|
+
|
|
693
723
|
Projects can customize a selected technology through its matching file, such
|
|
694
724
|
as `genesis/stack/jskit.md`:
|
|
695
725
|
|
|
@@ -313,8 +313,19 @@ app. A host lists every pass, with its title, description, recommendation hint,
|
|
|
313
313
|
and the runs it offers, through `inspectPasses()` or `genesis inspect passes
|
|
314
314
|
--json`, instead of naming them itself, and sends a run's `request` as written:
|
|
315
315
|
Genesis recognises its own run requests, adds the run's `PASS RUN` scope and
|
|
316
|
-
`PASS RECORD` step, and records nothing else.
|
|
317
|
-
|
|
316
|
+
`PASS RECORD` step, and records nothing else. Every pass prompt, whatever its
|
|
317
|
+
request, carries the `PASS REPORT` section, so its report states what it read
|
|
318
|
+
in full and what it only searched, with its coverage in numbers, and calls a
|
|
319
|
+
run whole only when it covered all of its scope. A deep run's prompt also
|
|
320
|
+
carries the shared `DEEP RUN` section. A pass the project's own Genesis
|
|
321
|
+
cannot run carries `unavailable` and no runs. Each pass's `sinceBase` gives the
|
|
322
|
+
request, and its deep form, of a run over the changes since a base commit the
|
|
323
|
+
host chooses (`{base}` stands for it), such as where a piece of work started;
|
|
324
|
+
Genesis scopes that run to the base and never records it. The listing's `master` entry is
|
|
325
|
+
the Master pass: a host sends its run's `request` for every pass, or its
|
|
326
|
+
`selectedRequest` with the chosen pass titles in place of `{passes}`, and the
|
|
327
|
+
`master-pass` prompt lists each pass's own Deep run request in its `MASTER PASS`
|
|
328
|
+
section; see [Passes](passes.md).
|
|
318
329
|
|
|
319
330
|
Once Codex identifies relevant source, `genesis context <path...>` returns only
|
|
320
331
|
Program modules citing those paths plus the effective engineering approach,
|
package/docs/stack-components.md
CHANGED
|
@@ -143,7 +143,7 @@ Concise technology context.
|
|
|
143
143
|
|
|
144
144
|
`Description`, `Guidance`, `Adoption`, `Post-change`, and each pass's section
|
|
145
145
|
(`Deslop`, `UI pass`, `Identity pass`, `Quality pass`, `Data pass`,
|
|
146
|
-
`Security pass`, `User experience pass`, `Speed pass`) are prose.
|
|
146
|
+
`Security pass`, `User experience pass`, `Speed pass`, `Review`) are prose.
|
|
147
147
|
`Requires` and `Conflicts` define component selection. `Skill` names one
|
|
148
148
|
complete authoritative Agent Skill directory. `Indexers` selects installed
|
|
149
149
|
structural adapters.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "genesis-compiler",
|
|
3
|
-
"version": "1.10.
|
|
3
|
+
"version": "1.10.23",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "An agent-independent prompt, multi-language code-index, cleanup, and verification companion with project agent guidance.",
|
|
6
6
|
"repository": {
|
|
@@ -39,6 +39,9 @@
|
|
|
39
39
|
"prompts/security-pass.txt",
|
|
40
40
|
"prompts/ux-pass.txt",
|
|
41
41
|
"prompts/speed-pass.txt",
|
|
42
|
+
"prompts/master-pass.txt",
|
|
43
|
+
"prompts/pass-report.txt",
|
|
44
|
+
"prompts/pass-deep.txt",
|
|
42
45
|
"prompts/program.txt",
|
|
43
46
|
"prompts/review.txt",
|
|
44
47
|
"prompts/start.txt",
|
|
@@ -57,7 +60,8 @@
|
|
|
57
60
|
"test": "node --test test/*.test.js"
|
|
58
61
|
},
|
|
59
62
|
"genesisContracts": {
|
|
60
|
-
"passRuns": "genesis.pass-runs.v1"
|
|
63
|
+
"passRuns": "genesis.pass-runs.v1",
|
|
64
|
+
"deepRuns": "genesis.deep-runs.v1"
|
|
61
65
|
},
|
|
62
66
|
"jskitRelease": {
|
|
63
67
|
"versionFiles": [
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
This Master pass task has already been rendered by Genesis. Do not generate
|
|
2
|
+
another Master pass prompt. Read and follow
|
|
3
|
+
`.agents/skills/genesis-master-pass/SKILL.md` completely.
|
|
4
|
+
|
|
5
|
+
This is an explicitly requested Master pass. It runs the passes listed under
|
|
6
|
+
MASTER PASS deeply, one after another in that order, each as that pass's own
|
|
7
|
+
Deep run from its own prompt. The Master pass adds only the order, the
|
|
8
|
+
checkpoint between passes, the ledger that lets an interrupted Master pass
|
|
9
|
+
continue, and one combined report; each pass's Deep run says how that pass
|
|
10
|
+
works, and each pass keeps its own limits on what it may change. Preserve
|
|
11
|
+
unrelated edits and existing staging: each pass commits only its own work.
|
|
12
|
+
|
|
13
|
+
Report, for each pass in order, its checklist count, what changed (what now
|
|
14
|
+
behaves differently, or, for a pass that keeps behaviour, that behaviour is
|
|
15
|
+
unchanged and how that was proven), its commits and the findings left
|
|
16
|
+
unchanged; then the passes skipped and why, how the work was split across
|
|
17
|
+
agents, and the final whole-suite run.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
A deep run works through every item in its scope and ticks each one only with
|
|
2
|
+
evidence a reader can check, because a search finds only what it looks for and
|
|
3
|
+
a report can be trusted only item by item.
|
|
4
|
+
|
|
5
|
+
Checklist first
|
|
6
|
+
|
|
7
|
+
- Before changing anything, write the checklist to the file named above, which
|
|
8
|
+
lives outside the project's tracked files and survives an interrupted run.
|
|
9
|
+
Start it with this run's request and the commit it starts from.
|
|
10
|
+
- Its items are every file of the project's own source in the scope that
|
|
11
|
+
PASS RUN states, each read in full, line by line, plus what this pass's skill
|
|
12
|
+
adds under "Deep run" for its lens.
|
|
13
|
+
- When PASS RUN starts the run from the changes since a commit, its items are
|
|
14
|
+
instead: every changed or added file; every file those changes call, are
|
|
15
|
+
called by or replace; the lens's items those changes touch; and, for each
|
|
16
|
+
change, a cross-check against the whole app for what elsewhere already does
|
|
17
|
+
what it adds and for older code it should have reused or now leaves dead.
|
|
18
|
+
That cross-check is how the run is judged against the whole app: a change
|
|
19
|
+
can duplicate, contradict or bypass code it never touches, so it needs
|
|
20
|
+
evidence like any other item. The report says plainly which files were read
|
|
21
|
+
in full and which were only searched against the whole app.
|
|
22
|
+
- A checklist already in that file for the same request that is not finished
|
|
23
|
+
is continued from its first unticked item rather than started again; any
|
|
24
|
+
other is replaced.
|
|
25
|
+
|
|
26
|
+
Ticks need evidence a reader can check
|
|
27
|
+
|
|
28
|
+
- Tick an item only when it says what was read and checked and points to
|
|
29
|
+
evidence someone else can verify: a test, by its file and name, that exists
|
|
30
|
+
and runs in the final whole-suite run; a measurement or output file the run
|
|
31
|
+
kept; a commit; or the command run and the refusal it saw.
|
|
32
|
+
- Prose alone, such as "checked, looks fine", never ticks an item the pass asks
|
|
33
|
+
to prove.
|
|
34
|
+
- An item not done stays unticked, with its reason. Never tick an item to
|
|
35
|
+
finish the run.
|
|
36
|
+
|
|
37
|
+
Chunks and several agents
|
|
38
|
+
|
|
39
|
+
- Work in chunks that follow the subsystem map (`genesis/subsystems.md` where
|
|
40
|
+
the project has one, otherwise its top-level source folders), the biggest
|
|
41
|
+
files first, because they hide the most.
|
|
42
|
+
- Where your host can run several agents (subagents or parallel workers), give
|
|
43
|
+
each chunk to its own agent, as many at once as the host's test budget and
|
|
44
|
+
limits allow, with the checklist as their shared record: one chunk at a time
|
|
45
|
+
takes far longer than the work needs. Coordinate them yourself, and do the
|
|
46
|
+
cross-subsystem pass and the final whole-suite run yourself, because only
|
|
47
|
+
the coordinator sees every chunk.
|
|
48
|
+
- A host that runs one agent works through the chunks in turn and still
|
|
49
|
+
completes the whole checklist.
|
|
50
|
+
- After the chunks, make one cross-subsystem pass for what no chunk alone can
|
|
51
|
+
see, as the skill's "Deep run" names it for this pass. It is an item with
|
|
52
|
+
evidence like any other.
|
|
53
|
+
|
|
54
|
+
Changes and commits
|
|
55
|
+
|
|
56
|
+
- The engineering approach's refactor rule, and the "Refactors keep behavior"
|
|
57
|
+
section of the sanity checks guide, apply to every change. The pass keeps its
|
|
58
|
+
own limits on what it may change.
|
|
59
|
+
- Commit your own work as you go, in small commits of one checklist item or
|
|
60
|
+
concern each, every message saying what changed and why, so each step can be
|
|
61
|
+
reviewed and undone on its own. Stage only this run's changes, never other
|
|
62
|
+
people's edits.
|
|
63
|
+
- Nothing of this run stays uncommitted at the end; this replaces the skill's
|
|
64
|
+
instruction to leave the pass as uncommitted work.
|
|
65
|
+
- End with one whole-suite run on the final committed tree.
|
|
66
|
+
|
|
67
|
+
Report
|
|
68
|
+
|
|
69
|
+
- Open with the checklist count, for example "212 of 212 items ticked with
|
|
70
|
+
evidence", then how many ticks rest on each kind of evidence: tests, kept
|
|
71
|
+
measurements or output, commits, and commands with the refusals they saw.
|
|
72
|
+
- List every unticked item with its reason, and every commit of the run.
|
|
73
|
+
- Say how the run was done: with several agents (how many, over which chunks),
|
|
74
|
+
or as one agent working through the chunks in turn.
|
|
75
|
+
- A pass whose contract keeps behaviour, such as Deslop, states that behaviour
|
|
76
|
+
is unchanged and how that was proven; any other pass states plainly what now
|
|
77
|
+
behaves differently.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
A pass report is how the person learns what was checked, so it never claims
|
|
2
|
+
more coverage than the run had.
|
|
3
|
+
|
|
4
|
+
- State the method: which parts of the scope you read in full, line by line,
|
|
5
|
+
and which you only searched or sampled, naming what each search looked for.
|
|
6
|
+
A search finds only what it was told to look for; code harder to follow than
|
|
7
|
+
it needs to be, parts grown too big, and logic that does one job in
|
|
8
|
+
different words show only when the code is read.
|
|
9
|
+
- State the coverage in numbers of the items the pass works through (files,
|
|
10
|
+
screens, tasks, ways in, waits), for example "41 of 107 files read in full;
|
|
11
|
+
the rest searched for repeated helpers, unused exports and direct storage
|
|
12
|
+
calls".
|
|
13
|
+
- Call the run "whole app", "complete" or "full" only when every item in its
|
|
14
|
+
scope was covered. Otherwise call it partial and name what was not covered
|
|
15
|
+
and why, so the next run can start there.
|
package/prompts/review.txt
CHANGED
|
@@ -47,7 +47,8 @@ Judge each against the matching section and outer limit of
|
|
|
47
47
|
`.agents/skills/genesis-project/references/sanity-checks.md`.
|
|
48
48
|
|
|
49
49
|
Edit only tests: add or update the tests the changed behavior lacks, and change
|
|
50
|
-
no product code, Blueprint, Program, Stack or other file
|
|
50
|
+
no product code, Blueprint, Program, Stack or other file; the record step that
|
|
51
|
+
ends this prompt, when there is one, is the only other write. Return a concise
|
|
51
52
|
report ordered by impact with exact file references, the evidence inspected,
|
|
52
53
|
the tests run and written, and the smallest sensible correction.
|
|
53
54
|
|
|
@@ -53,6 +53,10 @@ another agent and do not generate it again. This step composes the selected
|
|
|
53
53
|
Stack's data pass guidance and any project customization with the portable
|
|
54
54
|
contract below.
|
|
55
55
|
|
|
56
|
+
When the user asks for a deep run of this pass, pass its Deep request,
|
|
57
|
+
`Data pass the whole app deeply.`, exactly;
|
|
58
|
+
Genesis then adds the run's `DEEP RUN` section.
|
|
59
|
+
|
|
56
60
|
## Resolve the scope
|
|
57
61
|
|
|
58
62
|
Inspect `git status --short` and the staged and unstaged diffs before editing.
|
|
@@ -60,9 +64,11 @@ A dirty worktree is allowed. Preserve the existing index and unrelated work; do
|
|
|
60
64
|
not stage, stash, commit, or discard changes as a prerequisite.
|
|
61
65
|
|
|
62
66
|
When the prompt has a `PASS RUN` section, the request is one of the pass's own
|
|
63
|
-
runs
|
|
64
|
-
the whole app,
|
|
65
|
-
|
|
67
|
+
runs (the whole app, the changes since its last completed run judged against
|
|
68
|
+
the whole app, or a deep run) or a run over the changes since a base commit the
|
|
69
|
+
request names, and its scope is the one that section states, whatever the
|
|
70
|
+
defaults below say. A deep run's prompt also has a `DEEP RUN`
|
|
71
|
+
section; follow it with "Deep run" below.
|
|
66
72
|
|
|
67
73
|
- **The whole app (default).** Every table, collection or store, and every
|
|
68
74
|
path that reads or writes them.
|
|
@@ -80,10 +86,10 @@ Read the engineering approach's rules on query counts and realistic tests, and
|
|
|
80
86
|
these sections of the sanity checks guide
|
|
81
87
|
(`.agents/skills/genesis-project/references/sanity-checks.md`): "Never do
|
|
82
88
|
these", "Data: one owner per table", "Data: one source for each fact", "Data:
|
|
83
|
-
loading a dataset", "Data: each read asks for the rows it uses", "Data:
|
|
84
|
-
|
|
85
|
-
looks like; this pass applies them across the whole scope
|
|
86
|
-
find.
|
|
89
|
+
loading a dataset", "Data: each read asks for the rows it uses", "Data: batches
|
|
90
|
+
and background work", "Data: two changes at once" and "Inputs and access". They
|
|
91
|
+
describe what good looks like; this pass applies them across the whole scope
|
|
92
|
+
and fixes what they find.
|
|
87
93
|
|
|
88
94
|
Then list, for the scope: each table, collection or store with its one owner
|
|
89
95
|
(`genesis/subsystems.md` records data ownership), who reads and writes it, its
|
|
@@ -169,3 +175,14 @@ step only to the pass's own runs, whose requests it writes itself, so a data
|
|
|
169
175
|
pass of a section, commits or your own changes is never recorded as the pass;
|
|
170
176
|
neither is a pass that stopped early, was abandoned or still has failing
|
|
171
177
|
checks.
|
|
178
|
+
|
|
179
|
+
## Deep run
|
|
180
|
+
|
|
181
|
+
When the prompt has a `DEEP RUN` section, follow it: it says how the checklist,
|
|
182
|
+
evidence, chunks, commits and report work for every pass. This pass adds to the
|
|
183
|
+
checklist:
|
|
184
|
+
|
|
185
|
+
- every store or table, every query path with its counts at a few rows and at
|
|
186
|
+
a realistic size, and every migration, constraint and index;
|
|
187
|
+
- the cross-subsystem item: a store read or written by more than one owner,
|
|
188
|
+
and the same query written in several places.
|
|
@@ -55,6 +55,10 @@ to another agent and do not generate it again. This step composes the selected
|
|
|
55
55
|
Stack's technology-specific Deslop guidance and any project customization with
|
|
56
56
|
the portable contract below.
|
|
57
57
|
|
|
58
|
+
When the user asks for a deep run of this pass, pass its Deep request,
|
|
59
|
+
`Deslop the whole app deeply.`, exactly;
|
|
60
|
+
Genesis then adds the run's `DEEP RUN` section.
|
|
61
|
+
|
|
58
62
|
## Resolve the cleanup scope
|
|
59
63
|
|
|
60
64
|
Inspect `git status --short` and the staged and unstaged diffs before editing.
|
|
@@ -63,9 +67,11 @@ existing index and unrelated work. Do not stage, stash, commit, or discard
|
|
|
63
67
|
changes as a prerequisite or as part of cleanup.
|
|
64
68
|
|
|
65
69
|
When the prompt has a `PASS RUN` section, the request is one of the pass's own
|
|
66
|
-
runs
|
|
67
|
-
the whole app,
|
|
68
|
-
|
|
70
|
+
runs (the whole app, the changes since its last completed run judged against
|
|
71
|
+
the whole app, or a deep run) or a run over the changes since a base commit the
|
|
72
|
+
request names, and its scope is the one that section states, whatever the
|
|
73
|
+
defaults below say. A deep run's prompt also has a `DEEP RUN`
|
|
74
|
+
section; follow it with "Deep run" below.
|
|
69
75
|
|
|
70
76
|
Resolve the user's scope as follows:
|
|
71
77
|
|
|
@@ -170,3 +176,19 @@ step only to the pass's own runs, whose requests it writes itself, so a Deslop
|
|
|
170
176
|
of your own changes, a section or commits is never recorded as the pass;
|
|
171
177
|
neither is a pass that stopped early, was abandoned or still has failing
|
|
172
178
|
checks.
|
|
179
|
+
|
|
180
|
+
## Deep run
|
|
181
|
+
|
|
182
|
+
When the prompt has a `DEEP RUN` section, follow it: it says how the checklist,
|
|
183
|
+
evidence, chunks, commits and report work for every pass. This pass adds to the
|
|
184
|
+
checklist:
|
|
185
|
+
|
|
186
|
+
- each file read in full for code harder to follow than it needs to be, parts
|
|
187
|
+
grown too big to hold in mind at once, and logic that does one job in
|
|
188
|
+
different words, each tick naming the behaviours checked before and after;
|
|
189
|
+
- the cross-subsystem item: helpers and logic duplicated across subsystems,
|
|
190
|
+
including one job written in different words, and a pattern one subsystem
|
|
191
|
+
follows that another ignores.
|
|
192
|
+
|
|
193
|
+
Deslop's limits hold in a deep run: behaviour stays as it is, and a defect
|
|
194
|
+
found stays a follow-up finding, left unchanged.
|
|
@@ -52,6 +52,10 @@ as the instructions for this same turn; do not dispatch it to another agent and
|
|
|
52
52
|
do not generate it again. This step composes the selected Stack's identity pass
|
|
53
53
|
guidance and any project customization with the portable contract below.
|
|
54
54
|
|
|
55
|
+
When the user asks for a deep run of this pass, pass its Deep request,
|
|
56
|
+
`Give the whole app its visual identity deeply.`, exactly;
|
|
57
|
+
Genesis then adds the run's `DEEP RUN` section.
|
|
58
|
+
|
|
55
59
|
## Resolve the scope
|
|
56
60
|
|
|
57
61
|
Inspect `git status --short` and the staged and unstaged diffs before editing.
|
|
@@ -59,9 +63,11 @@ A dirty worktree is allowed. Preserve the existing index and unrelated work; do
|
|
|
59
63
|
not stage, stash, commit, or discard changes as a prerequisite.
|
|
60
64
|
|
|
61
65
|
When the prompt has a `PASS RUN` section, the request is one of the pass's own
|
|
62
|
-
runs
|
|
63
|
-
the whole app,
|
|
64
|
-
|
|
66
|
+
runs (the whole app, the changes since its last completed run judged against
|
|
67
|
+
the whole app, or a deep run) or a run over the changes since a base commit the
|
|
68
|
+
request names, and its scope is the one that section states, whatever the
|
|
69
|
+
defaults below say. A deep run's prompt also has a `DEEP RUN`
|
|
70
|
+
section; follow it with "Deep run" below.
|
|
65
71
|
|
|
66
72
|
- **The whole app (default).** Every screen or view a person sees, the shell,
|
|
67
73
|
sign-in, the loading screen, the logo and the icons. An identity is
|
|
@@ -265,3 +271,14 @@ step only to the pass's own runs, whose requests it writes itself, so an
|
|
|
265
271
|
identity pass of a section, commits or your own changes is never recorded as
|
|
266
272
|
the pass; neither is a pass that stopped early, was abandoned or still has
|
|
267
273
|
failing checks.
|
|
274
|
+
|
|
275
|
+
## Deep run
|
|
276
|
+
|
|
277
|
+
When the prompt has a `DEEP RUN` section, follow it: it says how the checklist,
|
|
278
|
+
evidence, chunks, commits and report work for every pass. This pass adds to the
|
|
279
|
+
checklist:
|
|
280
|
+
|
|
281
|
+
- every screen, every kind of content, each empty state, the loading screen,
|
|
282
|
+
sign-in, the logo and the icons;
|
|
283
|
+
- the cross-subsystem item: colours, artwork or type defined outside the one
|
|
284
|
+
module and theme, and any screen the identity has not reached.
|
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: genesis-master-pass
|
|
3
|
+
description: Run the project's passes deeply, one after another, through an explicitly requested Master pass over the whole app or the changes since its last completed run, every pass or the ones named, each as that pass's own Deep run, committed and tested before the next starts, with a ledger that lets an interrupted Master pass continue and one combined report. Use when asked for a Master pass, to run every pass, or to run several passes deeply in turn.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Genesis Master pass
|
|
7
|
+
|
|
8
|
+
Run the selected passes deeply, one after another, so the software comes out of
|
|
9
|
+
each one committed and tested before the next starts. A Master pass is
|
|
10
|
+
explicit: never run it merely because implementation finished.
|
|
11
|
+
|
|
12
|
+
Resolve the invocation before running the first Genesis operation. Do not use a
|
|
13
|
+
Genesis operation or `genesis --version` as an availability probe.
|
|
14
|
+
|
|
15
|
+
1. Read the repository-root `package.json`. Treat Genesis as project-pinned only
|
|
16
|
+
when that manifest's `name` is `genesis-compiler`, or its `dependencies`,
|
|
17
|
+
`devDependencies`, or `optionalDependencies` contain the exact
|
|
18
|
+
`genesis-compiler` key.
|
|
19
|
+
2. For a project-pinned repository, invoke every Genesis CLI operation with
|
|
20
|
+
`npm exec --no -- genesis <arguments>`. This runs without fetching another
|
|
21
|
+
package. If the declared package is not installed, report that the project's
|
|
22
|
+
dependencies are not prepared; do not fall back to another Genesis version.
|
|
23
|
+
3. Otherwise, do not try `npm exec`. Run `command -v genesis` (or the current
|
|
24
|
+
shell's equivalent `PATH` lookup). When it resolves an executable, invoke
|
|
25
|
+
`genesis <arguments>` directly.
|
|
26
|
+
4. When neither source is available, stop and report that Genesis is
|
|
27
|
+
unavailable. Never install or update Genesis merely to satisfy a workflow
|
|
28
|
+
instruction.
|
|
29
|
+
|
|
30
|
+
Successful invocation resolution is routine. Do not narrate whether Genesis is
|
|
31
|
+
project-pinned or on `PATH`, and never describe direct `PATH` use as a fallback.
|
|
32
|
+
Mention how the invocation was selected only when resolution fails or the user
|
|
33
|
+
explicitly asks.
|
|
34
|
+
|
|
35
|
+
Follow the configured Collaboration approach for user-facing updates, including
|
|
36
|
+
its technical depth and response length. Report concrete progress,
|
|
37
|
+
findings, or blockers; do not announce that you are following guidance.
|
|
38
|
+
|
|
39
|
+
## Load the effective project instructions once
|
|
40
|
+
|
|
41
|
+
A Master pass request may arrive as a complete Genesis-generated prompt or as a
|
|
42
|
+
direct request such as `Master pass` or `Master pass (security, data, deslop)
|
|
43
|
+
the whole app.`
|
|
44
|
+
|
|
45
|
+
If the current task already contains `GENESIS CONTEXT` whose task is
|
|
46
|
+
`master-pass`, continue with it directly. Do not generate another prompt.
|
|
47
|
+
|
|
48
|
+
Otherwise, run the Genesis `prompt --task master-pass` operation once using the
|
|
49
|
+
invocation rule above. For a bare `Master pass`, pass no request argument: it
|
|
50
|
+
runs every pass the project offers over the whole app. When the user names
|
|
51
|
+
passes, pass `Master pass (<their names>) the whole app.` with the names
|
|
52
|
+
separated by commas; a pass's id or title works, with or without "pass". When
|
|
53
|
+
the user asks for the changes since the last completed Master pass, pass that
|
|
54
|
+
run's request from `genesis inspect passes --json` exactly. Genesis refuses a
|
|
55
|
+
name it offers no pass for and names the passes it does; tell the user. Treat
|
|
56
|
+
the printed prompt as the instructions for this same turn and do not generate
|
|
57
|
+
it again.
|
|
58
|
+
|
|
59
|
+
## What the Master pass adds, and what it does not
|
|
60
|
+
|
|
61
|
+
The prompt's `MASTER PASS` section lists the passes to run, in order, each with
|
|
62
|
+
the exact request of its own Deep run. Run them in that order, whatever order
|
|
63
|
+
they were named in: the review first, so every later pass starts from tested
|
|
64
|
+
work, then security, so later passes build on the access it fixes, and Deslop
|
|
65
|
+
last, so it cleans up after what the others changed. If you see a reason in
|
|
66
|
+
this project for another order, say so in the report rather than changing it.
|
|
67
|
+
|
|
68
|
+
Each pass runs as that pass's own Deep run, from its own prompt. Its `DEEP RUN`
|
|
69
|
+
section says how the checklist, evidence, chunks, agents, commits and report
|
|
70
|
+
work, and its skill says what its lens adds and what it may change. The Master
|
|
71
|
+
pass never restates, shortens or loosens that guidance; it adds only the order,
|
|
72
|
+
the checkpoint between passes, the ledger and the combined report.
|
|
73
|
+
|
|
74
|
+
## Keep the Master ledger
|
|
75
|
+
|
|
76
|
+
Before the first pass, write the Master ledger at the path the `MASTER PASS`
|
|
77
|
+
section names. It lives in Git's own directory, outside the project's tracked
|
|
78
|
+
files, so an interrupted Master pass finds it again. Record the request, the
|
|
79
|
+
commit it starts from, and each listed pass with its status (to do, running,
|
|
80
|
+
done or skipped), the path of its checklist (the one its `DEEP RUN` names), its
|
|
81
|
+
commits and its checklist count. Update it as each pass starts and finishes.
|
|
82
|
+
|
|
83
|
+
When a ledger for the same request is already there and not finished, continue
|
|
84
|
+
from it: passes marked done stay done, and a pass marked running continues its
|
|
85
|
+
own checklist from its first unticked item. Any other ledger is replaced.
|
|
86
|
+
|
|
87
|
+
## Run each pass
|
|
88
|
+
|
|
89
|
+
For each listed pass, in order:
|
|
90
|
+
|
|
91
|
+
1. Mark it running in the ledger.
|
|
92
|
+
2. Generate its prompt with the Genesis `prompt` operation and the exact
|
|
93
|
+
request listed for it, for example `prompt --task security-pass "Security
|
|
94
|
+
pass the whole app deeply."`, and follow that prompt in full as this pass's
|
|
95
|
+
instructions, through its own `PASS RECORD` step, which records the pass on
|
|
96
|
+
its own so its next run since its last completed one starts there.
|
|
97
|
+
3. Where the host can run several agents, the pass gives its chunks to them as
|
|
98
|
+
its `DEEP RUN` says, as many as the host's test budget and limits allow, and
|
|
99
|
+
you coordinate them. The passes themselves run one after another, never at
|
|
100
|
+
the same time, because each one starts from the tree the last one committed.
|
|
101
|
+
4. Checkpoint before the next pass starts: every change of this pass is
|
|
102
|
+
committed, in small commits of one checklist item or concern each with
|
|
103
|
+
messages that say what changed and why; nothing is left uncommitted; and the
|
|
104
|
+
pass's final whole-suite run passed on the committed tree. Record its
|
|
105
|
+
commits and checklist count in the ledger and mark it done.
|
|
106
|
+
|
|
107
|
+
A pass that cannot finish, such as one whose failing checks it cannot fix,
|
|
108
|
+
stops the Master pass there: report where it stopped and why, and do not start
|
|
109
|
+
the next pass on a broken tree.
|
|
110
|
+
|
|
111
|
+
Skip a pass that does not apply to this software, such as the UI or identity
|
|
112
|
+
pass where the software has no screens, and write the reason in the ledger and
|
|
113
|
+
the report. Never skip a pass because it is long or hard.
|
|
114
|
+
|
|
115
|
+
## Record and report
|
|
116
|
+
|
|
117
|
+
Once every listed pass is done or skipped, take the prompt's `PASS RECORD` step:
|
|
118
|
+
the Genesis `passes done master-pass <pass id...>` operation, naming the passes
|
|
119
|
+
it ran and leaving out those it skipped, records the Master pass in
|
|
120
|
+
`genesis/passes-added.json`; commit that change as its last commit, so nothing is
|
|
121
|
+
left uncommitted and its next run since the last one starts there.
|
|
122
|
+
|
|
123
|
+
End with one combined report. Open with the passes run and skipped, and how the
|
|
124
|
+
work was split across agents (or that it ran as one agent). Then, for each pass
|
|
125
|
+
in order: its checklist count and how many ticks rest on each kind of evidence,
|
|
126
|
+
what changed, its commits, its unticked items and the findings left unchanged.
|
|
127
|
+
A pass that changes behaviour on purpose, such as the security, data or
|
|
128
|
+
quality pass, states plainly what now behaves differently; a pass that keeps
|
|
129
|
+
behaviour, such as Deslop, states that behaviour is unchanged and how that was
|
|
130
|
+
proven. For a run since the last Master pass, say which files each pass read in
|
|
131
|
+
full and which it only searched against the whole app. Close with the final
|
|
132
|
+
whole-suite run on the committed tree.
|