Skip to content

Commit 1d6b87b

Browse files
committed
docs(openspec): archive the stub recovery change
The change ships as a single PR, so the spec, the implementation, and the archive land together. The `cli-init` delta is applied into the main spec and the change directory moves under `archive/`, keeping `main` clean on merge.
1 parent 3927c29 commit 1d6b87b

4 files changed

Lines changed: 37 additions & 0 deletions

File tree

openspec/changes/stub-recovery-instruction/proposal.md renamed to openspec/changes/archive/2026-08-28-stub-recovery-instruction/proposal.md

File renamed without changes.

openspec/changes/stub-recovery-instruction/specs/cli-init/spec.md renamed to openspec/changes/archive/2026-08-28-stub-recovery-instruction/specs/cli-init/spec.md

File renamed without changes.

openspec/changes/stub-recovery-instruction/tasks.md renamed to openspec/changes/archive/2026-08-28-stub-recovery-instruction/tasks.md

File renamed without changes.

‎openspec/specs/cli-init/spec.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -683,3 +683,40 @@ When a prior install left a full skill or command copy in a tool directory, or l
683683
- **WHEN** `taskless update` finds `.claude/skills/taskless` recorded as a target but present on disk as a symlink
684684
- **THEN** update SHALL replace the symlink with a real reference stub file
685685
- **AND** SHALL NOT write through the symlink into another directory
686+
687+
### Requirement: A reference stub says how to restore a missing canonical file
688+
689+
A reference stub's body SHALL state what to do when the canonical file it points at is not present, naming a command that restores it. A stub that only delegates leaves a reader who follows it at a dead end, and the two states that produce a missing canonical file (an install whose untracked files never reached this working directory, and a project that ignores the canonical store) are both reached without anyone doing anything wrong.
690+
691+
Skill stubs and command stubs SHALL carry the same instruction.
692+
693+
The command named SHALL be the one that runs the build which wrote the stub, resolved the same way canonical content resolves it. A stub emitted by a development or nightly build SHALL NOT direct the reader to the released package.
694+
695+
The command named SHALL install without an interactive terminal, since the reader of a stub is typically an agent in a non-interactive context.
696+
697+
Stub content SHALL carry nothing that varies per release, so that adding this instruction changes the footprint outside the canonical store exactly once.
698+
699+
A stub already on disk whose body predates this instruction SHALL be rewritten once by the next install, rather than waiting for its frontmatter to change. Detection of such a stub SHALL NOT depend on the build that wrote it, so that builds with different invocations do not rewrite one another's stubs.
700+
701+
#### Scenario: Stub names the command that restores a missing canonical file
702+
703+
- **WHEN** the CLI writes a skill stub or a command stub
704+
- **THEN** its body SHALL say what to do if the canonical file does not exist
705+
- **AND** SHALL name a command that restores it
706+
707+
#### Scenario: A development build points at itself
708+
709+
- **WHEN** a `dev` or `self` build writes a stub
710+
- **THEN** the command named SHALL be that build's own invocation
711+
- **AND** SHALL NOT be the released package
712+
713+
#### Scenario: Stub bytes do not move with the CLI version
714+
715+
- **WHEN** two installs of different CLI versions write a stub for the same skill
716+
- **THEN** the two stubs SHALL be identical
717+
718+
#### Scenario: An older stub is rewritten once
719+
720+
- **WHEN** an install finds a stub whose body carries no recovery instruction
721+
- **THEN** the install SHALL rewrite that stub
722+
- **AND** a subsequent install SHALL leave the rewritten stub untouched

0 commit comments

Comments
 (0)