Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 12 additions & 11 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@ ci/ everything that only exists to test/build the module
selftest.sh negative controls for the gate itself
fixtures/policy/ trees the policy checks must go RED on
PROMPT.md adopt this standard in another module:
eleven checkpoints in six phases
63 steps in seven phases
.githooks/pre-commit tracked commit gate (opt in: core.hooksPath)
.github/
versions.env version + sha256 pins, single source of truth
Expand Down Expand Up @@ -296,23 +296,24 @@ Read /opt/myguard/labs/nginx-skeleton-module/ci/PROMPT.md and apply it to
/path/to/nginx-<name>-module.
```

Eleven checkpoints in six phases, one PR each after the read-only first:
inventory, the decision seam, the `ci/` layout, runner identity, workflows +
badges + a single entry point, the four test layers, fuzzing, caching + the
linter gate, lanes, self-hosted exposure, and a final depth pass asking whether
any of the now-green gates would actually catch anything. Two phases carry no
checkpoint of their own: one ahead of all of them sets the scope jail and the
stop conditions, and one at the end closes out the docs, the memory mirror and
the report. Checkpoint 0 works out how much of it the target already has, so you
do not need to know in advance whether this is a first adoption or a top-up.
63 steps in seven phases, covering: inventory, the decision seam, the `ci/`
layout, runner identity, workflows + badges + a single entry point, the four
test layers, fuzzing, caching + the linter gate, lanes, self-hosted exposure,
and a depth pass asking whether any of the now-green gates would actually catch
anything. A step is a **grind unit, not a PR** — it is sized to be handed to a
cheap model with the file and nothing else, and steps land in groups across 14
fixed PR boundaries that must not be merged partially. The last phase is the
aftermath: the checks worth running once the adoption is green. Steps 1–6 work
out how much of the standard the target already has, so you do not need to know
in advance whether this is a first adoption or a top-up.
Comment on lines +299 to +308

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Align the PR-granularity rule with the workflow table.

README.md now states that steps land in groups across 14 fixed PR boundaries. ci/PROMPT.md Lines 39–58 defines those groups. However, ci/PROMPT.md Lines 82–84 still says “One PR per step that lands code” and requires the previous step to merge first. An adopter cannot follow both instructions. Update the standing constraint to describe the fixed PR groups, including the 12+ depth-pass exception.


It is a **merge into whatever CI the target already has**, not a greenfield
install — the target's tests, thresholds and extra gates survive; the layout,
ordering, naming and entry points become the standard's. A final section covers
the inverse job once a module is fully adopted: forwarding one later skeleton
change into it.

**Settle the runner question first** (checkpoint 2 of the prompt). These
**Settle the runner question first** (steps 13–15 of the prompt). These
Comment on lines 310 to +316

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Align the runner prerequisite step number.

README.md points adopters to steps 13–15. The phase and PR tables in ci/PROMPT.md also assign runner identity to steps 13–15. However, ci/PROMPT.md Line 77 still says “Step 7 settles it.” Step 7 is the decision-seam phase. Update the stale reference so the adoption sequence has one runner prerequisite.

Proposed documentation fix
- Step 7 settles it before any workflow is ported.
+ Steps 13–15 settle it before any workflow is ported.

workflows name `builder02`, a machine myguard owns, in 15 `runs-on` selectors
plus `.github/actionlint.yaml` and `TRUST_SPLITS` in `workflow_policy.py` — and
**no linter in this repo will tell an adopter they copied it**: actionlint
Expand Down
4 changes: 2 additions & 2 deletions ci/PROMPT.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,8 +102,8 @@ Standing constraints, all steps:

**Default to proceeding.** This job runs unattended. Almost everything that used
to be a stop is now a recorded finding: you write it down, degrade the affected
step honestly, and carry on with the remaining 59. A run that stops at step 3
with a question delivers nothing; a run that finishes 52 of 54 steps and hands
step honestly, and carry on with the remaining 60. A run that stops at step 3
with a question delivers nothing; a run that finishes 61 of 63 steps and hands
back a precise list of the 2 it could not do delivers almost everything.

Two files carry what you cannot act on. Create both at the start of step 1:
Expand Down
2 changes: 1 addition & 1 deletion ci/feedback/README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Adoption feedback

Findings sent back here by modules that adopted this skeleton — the half of
[step 23](../PROMPT.md) that could not be fixed in code.
[step 49](../PROMPT.md) that could not be fixed in code.

The skeleton is only worth keeping if it stays ahead of its clones, and an
adopter is the only party who ever runs it against an unfamiliar module. What
Expand Down
Loading