-
Notifications
You must be signed in to change notification settings - Fork 0
Pipeline Design 39
Shipwright uses an AUTO-section system (HTML comment markers <!-- AUTO:section-id --> / <!-- /AUTO:section-id -->) to keep documentation tables synchronized with source code. The shipwright docs sync command regenerates these sections by scanning script files for line counts, purpose comments, and structural metadata.
10 AUTO sections across 5 files are stale. The drift is limited to line-count values for 3 scripts:
| Script | Documented | Actual | Delta |
|---|---|---|---|
scripts/sw-loop.sh |
3361 | 3395 | +34 |
scripts/sw-pipeline.sh |
2877 | 2875 | -2 |
scripts/sw-lib-pipeline-detection-test.sh |
598 | 604 | +6 |
The affected sections (core-scripts and test-suites) are replicated across 5 generated/mirrored instruction files. No structural changes (new files, renamed scripts, changed purposes) are involved.
Use the existing shipwright docs sync command to regenerate all stale AUTO sections in a single pass. This is the canonical mechanism — no manual edits, no partial updates. The sync command reads actual file metadata and rewrites each AUTO block in-place.
The approach is deterministic: the sync command produces identical output regardless of how many sections are stale, so running it once covers all 10 stale sections across all 5 files. Verification is done via shipwright docs check (exit 0 = all fresh).
No new patterns, data flows, or error handling are introduced. This is a maintenance operation using existing tooling.
-
Manual line-count edits — Pros: Surgical, no tooling dependency / Cons: Error-prone across 5 files (15 individual edits), bypasses the sync system that exists precisely for this purpose, risks introducing typos or inconsistencies between the mirrored files.
-
Sync only the stale files individually — Pros: Smaller diff surface / Cons:
shipwright docs syncalready operates idempotently on all files; selectively running it adds complexity for zero benefit. Fresh sections are untouched by the sync. -
Ignore the staleness — Pros: No work / Cons: Stale line counts erode trust in documentation accuracy,
shipwright docs checkfails (exit 1), CI workflow (shipwright-docs.yml) would flag this on next push to main.
- Files to create: none
- Files to modify:
-
.ai-standards/generated/claude-instructions.md—core-scriptsandtest-suitessections -
.ai-standards/generated/codex-instructions.md—core-scriptsandtest-suitessections -
.ai-standards/generated/copilot-instructions.md—core-scriptsandtest-suitessections -
.github/copilot-instructions.md—core-scriptsandtest-suitessections -
AGENTS.md—core-scriptsandtest-suitessections
-
- Dependencies: none (uses existing
shipwright docs sync) - Risk areas: Effectively none. The sync is idempotent and only modifies content between AUTO markers. The diff should show exactly 3 line-count value changes replicated across 5 files (15 insertions, 15 deletions). Any deviation from this pattern indicates an unexpected change that should be reviewed before committing.
-
shipwright docs checkexits 0 with 30/30 sections fresh -
git diff --statshows exactly 5 files changed -
git diffshows only line-count numeric changes forsw-loop.sh(3361→3395),sw-pipeline.sh(2877→2875), andsw-lib-pipeline-detection-test.sh(598→604) - No untracked or unexpected files introduced
- Commit is on branch
docs/stale-documentation-detected-39with clean status after push