Skip to content

chore(deps): bump vendor/spec-kit from v1.0.5 to v1.0.6 (supersedes #17) - #18

Merged
forkrul merged 2 commits into
masterfrom
claude/screen-warp-fonts-research-uksv3z
Sep 11, 2026
Merged

forkrul merged 2 commits into
masterfrom
claude/screen-warp-fonts-research-uksv3z

Conversation

@forkrul

@forkrul forkrul commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Supersedes #17.

Why #17 cannot be merged

Dependabot aimed at 4a7341a, an untagged mid-stream commit on spec-kit's default branch. The repo's pinning rule ("only merge bumps that land on an upstream tag") is enforced mechanically by the shellcheck + repo integrity job, which fails with:

##[error]vendor/spec-kit is at 4a7341a, which is not an upstream tag

That PR is red by design and no amount of rebasing changes it. It should be closed rather than merged.

What this does instead

Bumps to v1.0.6 (96c9bd6) — the next actual upstream tag after the current pin v1.0.5 (a4e25ce).

The README vendored-submodules table moves with the pin, because the same CI step also greps it for | <tag> | and fails when table and pin disagree.

The dependency that actually matters

anvil's fallback path reads three templates from this submodule. All three still exist at v1.0.6:

vendor/spec-kit/templates/spec-template.md
vendor/spec-kit/templates/plan-template.md
vendor/spec-kit/templates/tasks-template.md

Upstream changes in the range are the 1.0.6 version bump, a generated-dispatcher stdin fix, a SPECIFY_FEATURE docs correction, and stale-bot timing — nothing touching the template layout.

Verification (run locally before pushing)

  • bash -n install.sh tests/smoke.sh — clean
  • Submodule-tag + README-table gate, the one that fails on chore(deps): bump vendor/spec-kit from a4e25ce to 4a7341a #17: vendor/superpowers @ v6.3.0, vendor/spec-kit @ v1.0.6, both listed in the README table
  • Alias symlinks resolve to stage dirs; every skills/*/SKILL.md and agents/*.md has name + description frontmatter
  • Every upstream superpowers skill still classified KEEP (in install.sh) or DENY (in README) — unchanged by this bump, but checked because the same job enforces it
  • tests/smoke.sh — OK on bash 5.2.21

shellcheck isn't installed in this environment; CI covers it, and no shell file changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NQQrX3uYoeNyqxYkSbRp2W


Generated by Claude Code

Supersedes #17, which Dependabot aimed at 4a7341a — an untagged mid-stream
commit. CI enforces the repo's pinning rule directly ("vendor/spec-kit is at
4a7341a, which is not an upstream tag"), so that PR could never go green.
v1.0.6 (96c9bd6) is the next actual upstream tag.

The README vendored-submodules table moves with the pin, because the same CI
step greps it for "| <tag> |" and fails when the table and the pin disagree.

anvil's dependency is the three fallback templates, and all three still exist
at v1.0.6: templates/{spec,plan,tasks}-template.md.

Verified locally: bash -n; the submodule-tag + README-table gate passes for
both submodules (superpowers @ v6.3.0, spec-kit @ v1.0.6); alias symlinks and
SKILL.md frontmatter intact; every upstream superpowers skill still classified
KEEP or DENY; tests/smoke.sh OK on bash 5.2.21.

Feature: vendor-pin-maintenance
Symbol: vendor/spec-kit,SUPERPOWERS_KEEP

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NQQrX3uYoeNyqxYkSbRp2W
[Unreleased] carries a note that everything in it is new and there is no
earlier release to change against, so a `### Changed` entry would be wrong:
v1.0.5 was never shipped. The Added line that names the vendored pins is the
entry to move, which is also what the eventual 0.1.0 release should read.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NQQrX3uYoeNyqxYkSbRp2W
@forkrul
forkrul merged commit c68d6b3 into master Sep 11, 2026
4 checks passed
forkrul pushed a commit that referenced this pull request Sep 18, 2026
…-Fxq

`--verify` intermittently condemned a healthy link as stale on macOS, failing
the smoke job on master (run 29, 20d91bf) and again on #18's first commit:

    install.sh: line 104: printf: write error: Broken pipe
    [ERR] stale damascus-owned link: .../.claude/skills/bdd-tdd-execution
    [ERR] 1 problem(s) found — re-run install.sh to repair
    FAIL: --verify failed after repair

Four call sites asked "is this name one we ship?" as `<emit names> | grep -Fxq`.
grep matches correctly and exits on the first hit — but every name emitted after
that hit then writes into a closed pipe, and `set -o pipefail` (line 16) promotes
that EPIPE to the pipeline's exit status. So a name damascus DOES ship reads as
one it does not, and the link is pruned or flagged.

Only a match that is not the last line emitted can trigger it, and only when the
producer is slower than grep — hence macOS-only and intermittent. The victim was
`bdd-tdd-execution`, an alias that is not last in ALIASES.

Reproduced deterministically by making the producer slower than the consumer: a
match on the first or a middle name reads as MISSED through the pipe and MATCH
through a loop; a match on the last name reads correctly through both, because
nothing is written after it.

`expected_skill_names` (emitter) becomes `is_expected_skill` (predicate), plus
`is_expected_agent` for the two AGENTS sites. Plain loops with an early return:
no subshell, no pipe, no reader that can exit first. bash 3.2 safe, and the
`if ...; then return 0; fi` form avoids the `&& return` errexit footgun.

Verified: all 25 shipped names (6 stages, 8 KEEP, 6 aliases, 5 agents) accepted,
including bdd-tdd-execution; unknown names still rejected; smoke suite 10/10
consecutive runs with zero "Broken pipe" in the output; sourcing guard intact so
CI can still read the manifests.

CHANGELOG records the guarantee on the existing install.sh Added line rather
than as a Fixed entry: [Unreleased] states there is no earlier release to fix
against, and this bug never shipped in one.

Feature: install-link-verification
Symbol: is_expected_skill,is_expected_agent,expected_skill_names,pipefail,SIGPIPE
Errors: write error: Broken pipe,stale damascus-owned link,--verify failed after repair

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NQQrX3uYoeNyqxYkSbRp2W
forkrul added a commit that referenced this pull request Sep 18, 2026
…-Fxq (#19)

--verify intermittently condemned a healthy link as stale on macOS, failing the
smoke job on master (run 29, 20d91bf) and again on #18's first commit:

    install.sh: line 104: printf: write error: Broken pipe
    [ERR] stale damascus-owned link: .../.claude/skills/bdd-tdd-execution
    FAIL: --verify failed after repair

Four call sites asked "is this name one we ship?" as `<emit names> | grep -Fxq`.
grep matches correctly and exits on the first hit, but every name emitted after
that hit writes into a closed pipe, and `set -o pipefail` promotes the EPIPE to
the pipeline's status — so a name damascus DOES ship reads as one it does not.

Only a match that is not the last line emitted can trigger it, and only when the
producer is slower than grep: macOS-only and intermittent. The victim was
bdd-tdd-execution, an alias that is not last in ALIASES.

expected_skill_names (emitter) becomes is_expected_skill (predicate), plus
is_expected_agent for the two AGENTS sites — plain loops with an early return,
no subshell, no pipe, no reader that can exit first. bash 3.2 safe.

Verified: all 25 shipped names accepted, unknown names still rejected, smoke
10/10 consecutive with zero "Broken pipe", sourcing guard intact.

Feature: install-link-verification
Symbol: is_expected_skill,is_expected_agent,expected_skill_names,pipefail,SIGPIPE
Errors: write error: Broken pipe,stale damascus-owned link,--verify failed after repair
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants