Pin verified loader versions in piSpawnSkill comment - #774
Closed
clkao wants to merge 2 commits into
Closed
Conversation
clkao
changed the base branch from
spacedock-ensign/embed-stage-report-protocol-in-dispatch
to
spacedock-ensign/gate-pi-frontdoor-bootstrap-on-resume
August 27, 2026 06:35
clkao
force-pushed
the
spacedock-ensign/pi-spawn-skill-name-resolution
branch
from
August 27, 2026 06:36
18f404b to
1b921d3
Compare
Drop the Pi-only stageReportFormatBlock() embed and its step-8a conditional from the dispatch body. The body no longer carries the stage-report protocol template; a stacked follow-up layer rewrites the Pi firstActionBlock to invoke the ensign skill instead. Remove the body-presence assertions that depended on the embed: - TestBuildPiArtifactCarriesStageReportProtocol (internal/dispatch) - TestPiNonSelfDescribingDispatchBuildBodyCarriesProtocol (internal/ensigncycle) Keep TestBuildPiFirstActionNarrowedToStageReportFormat (overclaim gone), the live lane (TestLivePiNonSelfDescribingDispatch), and the CI wiring. The live lane will fail in pi-live until the follow-up layer rewrites firstActionBlock to invoke the skill — that is the point (the lane proves the fix).
clkao
force-pushed
the
spacedock-ensign/pi-spawn-skill-name-resolution
branch
2 times, most recently
from
August 27, 2026 07:44
8b8154d to
a308052
Compare
Rewrite the Pi firstActionBlock to direct the worker to load the ensign discipline BEFORE reading the dispatch file, mirroring Claude's Skill(skill="spacedock:ensign") and Codex's $spacedock:ensign bootstrap. The worker is told to run /skill:ensign (Pi's skill-invoke slash command) or fall back to reading skills/ensign/SKILL.md and its references/, then read the dispatch file for the stage-specific assignment. This drops the false claim that the dispatch file itself contains the ensign discipline entry points (the skill is in available_skills but the worker must be told to load it). Also revert the comment-only piSpawnSkill loader-version pin from the prior (wrong-scope) commit; piSpawnSkill="ensign" is unchanged. Add offline guard TestPiFirstActionInvokesEnsignSkill asserting the firstActionBlock contains a skill-load instruction (/skill:ensign or skills/ensign/SKILL.md), does not carry the false claim, and loads the skill before the read-dispatch-file instruction. Update two sibling tests whose body assertions referenced the old firstActionBlock phrase.
clkao
force-pushed
the
spacedock-ensign/pi-spawn-skill-name-resolution
branch
from
August 27, 2026 07:45
a308052 to
4690b53
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A field report claimed Pi-dispatched ensigns spawn contract-free because the dispatch artifact passes the bare skill name
"ensign"while "newer Pi wants the exact namespacedock:ensign." The report's diagnosis is inverted: the bare basename is the only form that resolves; the qualified name would fail.What changed
internal/dispatch/build.go: comment-only refinement of thepiSpawnSkillblock (lines 56-66) — replaced the stale unverified assumption ("pi-subagents resolves agents and skills by directory basename only") with pinned re-verification evidence.piSpawnSkillremains"ensign",piSpawnAgentremains"worker"— byte-identical to main (only line numbers shifted). No behavior change.Evidence
resolveSkillPathinpi-subagents/src/agents/skills.tsis byte-identical on installed 0.37.2 and latest npm 0.57.0 — both useskills.find((s) => s.name === skillName)(exact basename match, no namespace handling).normalizeSkillInputonly trims whitespace; no colon-splitting that would turnspacedock:ensignintoensign. Passingspacedock:ensignwould fail to resolve and land inmissing→ contract-free boot.<available_skills>— the bare name resolves end-to-end.TestBuildPiHostEmitsSpawnAgentAndSkillasserts the artifact emitsskill = "ensign"andagent = "worker", locking the verified-correct values. PASS;go build ./...OK; gofmt clean.git diff --numstat mainshows onlybuild.go(6/1), comment lines only.The report likely confused the
subagent_typefield (host-neutral"spacedock:ensign") with theskillfield (bare"ensign") — two different fields that coexist on the artifact.ntn