Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Pipeline Design 39

ezigus edited this page Mar 1, 2026 · 2 revisions

Design: Stale documentation detected

Context

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.

Decision

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.

Alternatives Considered

  1. 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.

  2. Sync only the stale files individually — Pros: Smaller diff surface / Cons: shipwright docs sync already operates idempotently on all files; selectively running it adds complexity for zero benefit. Fresh sections are untouched by the sync.

  3. Ignore the staleness — Pros: No work / Cons: Stale line counts erode trust in documentation accuracy, shipwright docs check fails (exit 1), CI workflow (shipwright-docs.yml) would flag this on next push to main.

Implementation Plan

  • Files to create: none
  • Files to modify:
    • .ai-standards/generated/claude-instructions.mdcore-scripts and test-suites sections
    • .ai-standards/generated/codex-instructions.mdcore-scripts and test-suites sections
    • .ai-standards/generated/copilot-instructions.mdcore-scripts and test-suites sections
    • .github/copilot-instructions.mdcore-scripts and test-suites sections
    • AGENTS.mdcore-scripts and test-suites sections
  • 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.

Validation Criteria

  • shipwright docs check exits 0 with 30/30 sections fresh
  • git diff --stat shows exactly 5 files changed
  • git diff shows only line-count numeric changes for sw-loop.sh (3361→3395), sw-pipeline.sh (2877→2875), and sw-lib-pipeline-detection-test.sh (598→604)
  • No untracked or unexpected files introduced
  • Commit is on branch docs/stale-documentation-detected-39 with clean status after push

Clone this wiki locally

AltStyle によって変換されたページ (->オリジナル) /