feat: add status command change proposal - #5
Merged
Merged
Conversation
This was referenced Feb 21, 2026
binbinao
pushed a commit
to binbinao/OpenSpec
that referenced
this pull request
May 31, 2026
问题原因: Windows PowerShell 5.1 默认使用系统编码(GBK),无法正确识别不带BOM的UTF-8文件。 当向PowerShell profile写入包含中文字符的注释时,PowerShell无法正确解析, 导致每次打开终端时报错。 修复内容: - 在powershell-installer.ts中所有写入.ps1文件时添加UTF-8 BOM标记 - 修复configureProfile、removeProfileConfig、install方法中的文件写入 - 添加BOM去除逻辑用于比较文件内容时正确判断是否已是最新版本 - 更新相关测试用例以验证BOM标记 Closes Fission-AI#5
DumoeDss
referenced
this pull request
in DumoeDss/rasen
Jul 9, 2026
…onical VERIFY VERDICT, tree-fingerprint evidence, never-read-source scoping Closes the gap where verify-change and verify-enhanced computed a verdict but never persisted a machine-checkable evidence artifact, so ship's pre-flight test-skip gate had no canonical verify output to key off, and the verify-family's severity classifications weren't tied to child #1's canonical vocabulary. Also closes a "never read source code" absolute-without-scope gap in the shared QA/DESIGN methodology blocks, and a pre-existing chrome-use parity coverage gap. - WF-1 (evidence file + ship pre-flight wiring): verify-change.ts (both skill and command getters) adds a Save Report step writing rasen/changes/<name>/verification-report.md with the summary scorecard, verdict status line, and grouped findings. - WF-7 (verdict unification, consumes canonical-severity-vocabulary): verify-change maps CRITICAL/WARNING/SUGGESTION and verify-enhanced maps Critical Issues/Warnings/per-stage PASS-FAIL onto canonical Blocker/Major/Minor/Trivial by reference (no re-declaration); per-stage PASS/FAIL kept as a display aid in verify-enhanced. - WF-8 (test-evidence chain): both verify getters emit the machine-checkable "VERIFY VERDICT: <CLEAN|BLOCKED> — Blocker:<n> Major:<n> Minor:<n> Trivial:<n>" status line (CLEAN iff no open Blocker/Major) and record a tree-fingerprinted test-evidence block (command(s) + result + git rev-parse HEAD^{tree}) when they run any test/gate command, matching the review-cycle schema. ship.ts adds verification-report.md to the pre-flight verification-evidence list and names it explicitly in the test-skip gate's evidence sources (skip-gate logic itself unchanged). - SH-1/SH-2 + RV-6/RV-7 (enumerate-and-gate scoping): _shared.ts QA_METHODOLOGY (#5/#7) and DESIGN_METHODOLOGY (#4) "never read source code" absolutes scoped to the exploration/testing/audit phase, with an explicit carve-out naming (a) diff-aware triage and (b) the STANDALONE fix loop — does not reopen child #1's dispatched-mode report-only contract. - D5: chrome-use added to the parity table (functionFactories + GENERATED_SKILL_FACTORIES + both hash maps), closing a pre-existing blind spot noted in the office-hours-dialogue-override review. Installed skills regenerated via node build.js (pnpm build still broken by the in-flight pnpm-workspace.yaml — confirmed identical output). Parity hashes resynced for qa, qa-only, design-review, plus the new chrome-use entries; verified no other template's hash moved. Reviewed CLEAN (review-cycle round 1, non-author confirmed): 1 Minor fixed (verify-change's Save-Report prose falsely claimed /rasen:retro reads verification-report.md — retro.ts's Outcome Artifacts list never enumerates it; trimmed the false claim, /rasen:ship — the real, correctly-wired consumer — remains named), 2 Trivial accepted-known (qa-only carve-out clause (b) references a fix loop qa-only doesn't have, harmless since it only permits; verify-enhanced omits restating "content overrides label" inline, relying on the referenced canonical-severity-vocabulary instead — acceptable by-reference pattern). ship.ts/verify-enhanced.ts absence from the parity registry (they're commands, not templates) is a pre-existing scope gap, not introduced here — relayed to child #3/#5 if in scope there. No whole-file branding-bundling residue this ship: unlike child #1 (which landed mid-rebrand), the rebrand session's openspec->rasen rename is already committed (2ebfae9, ca54b3b), so these 5 files carry no in-flight branding churn — no LEAD ruling needed here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DumoeDss
referenced
this pull request
in DumoeDss/rasen
Jul 9, 2026
…evival, two-threshold rule, counter disambiguation Closes a family of ambiguities in the LEAD orchestration playbook (_orchestration.ts, auto.ts, goal-command.ts) around worker death, threshold counters, and gate semantics — cases where the same-sounding number or event was governed by two different rules depending on context, with no explicit disambiguation. - OR-1/SH-4 threshold families: relay caps, stall limits, and round caps disambiguated — each named explicitly and scoped to the lifecycle event it governs. - H.4/OR-6 worker-death taxonomy + infra revival: two-branch taxonomy — (a) genuine work-exhaustion (HANDOFF) vs (b) infrastructure death (process/connection failure). An infra-death SendMessage-triggered revival is NOT charged against the relay/ stall caps that govern (a). The (a)-vs-(b) boundary has a documented residual ambiguity, accepted in design Risks as cheap/self-correcting (a genuinely-full worker HANDOFFs on the wake turn and gets reclassified). - OR-9/OR-13/OR-15 counter disambiguation: a counter table maps every counter token (maxRelays, stallLimit, maxRounds, loop.maxRounds, strategyAttempts, loopStallLimit, sessionHandoff.n) to its exact governing rule — grep-audited, no orphans. - Tier-C degradations (OR-4, OR-14): LEAD never self-certifies a Tier-C implementer's work without an independent check. verifyPolicy standard/light modes defined in auto.ts section 5 (verify stages only run under the auto command). - OR-8/OR-11/SH-5/SH-7: SH-5 scopes the LEAD's "flag it" duty — an out-of-scope issue the LEAD notices routes to DONE durable-findings, not autonomous investigate/fix/ask-user; explicitly disclaims reopening child #1's dispatched-mode report-only contract. SH-7 defines a narrow inline-fix exception. - Gate directive precedence (D6, LEAD ruling): Step G resolves how a decomposed portfolio's child-pipeline gates behave with no explicit parent gate directive — default is auto-continue (record the checkpoint, do not pause per child), since irreversible actions already collapse to the single portfolio-level delivery decision. Reversible product decision, surfaced to the user in the ship log rather than silently baked in. Round 2 tightened Step G's prose after the reviewer flagged that the wording could be misread as the opposite default — behavior unchanged, wording clarified. _orchestration.ts/auto.ts/goal-command.ts are NOT in the parity golden-master registry (pre-existing gap). Verified instead via node build.js + node dist/cli/index.js update succeeding, plus 5 independent grep spot-checks against the regenerated rasen-auto/ rasen-review-cycle/commands-auto output confirming the new prose is present verbatim, performed independently by implementer and reviewer. Registry expansion relayed to child #5 (prompt-audit-fixes-lifecycle), along with a newly-discovered, distinct gap: rasen-goal/goal-plan templates are absent from the generation registry entirely, not just the parity registry. Installed skills regenerated via node build.js. Parity hashes resynced for the 15 PREAMBLE-importing expert templates (careful/freeze/guard/unfreeze correctly show zero movement — they do not import PREAMBLE; a task-note miscount of "19" was corrected to 15 in fix round 1). Reviewed CLEAN APPROVED (review-cycle, 2 rounds, non-author confirmed). Round 1: 1 Minor fixed (auto.ts's gate guardrail lacked a back-reference to Step G's precedence rule — added a scoped cross-reference), 1 Trivial fixed (tasks.md miscounted PREAMBLE embedders as 19, corrected to 15). Round 2: 1 new Minor found and fixed (Step G sentence 1's "does NOT suppress ... by default" wording could be misread as contradicting the D6 auto-continue default — tightened without changing behavior). Seam integrity confirmed: child #1's Step B report-contract sentence and child #2's verify/ship evidence chain both verified untouched by this diff. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DumoeDss
referenced
this pull request
in DumoeDss/rasen
Jul 9, 2026
Moves the completed prompt-audit-fixes-lifecycle change (child #5 of the prompt-audit-fixes portfolio) to rasen/changes/archive/2026-07-09-prompt-audit-fixes-lifecycle/ and syncs its six delta specs into rasen/specs/: NEW capabilities: - lifecycle-stage-sequencing: apply/continue completion messages steer through the intended stage sequence (verify -> ship -> archive) instead of offering archive as an immediate co-equal step. - workflow-template-parity: the workflow/orchestration skill and command templates outside the expert set are now pinned by the parity golden master, mirroring the expert templates and chrome-use. MODIFIED capabilities: - propose-workflow (ADDED-only): consumes office-hours validation output as input context, checking both the change dir and the sibling office-hours directory by slug. - opsx-office-hours-command (ADDED-only): facilitation delegates to the /office-hours expert as the single authority; inline six-questions/builder text becomes a fallback pre-brief only. - orchestration-worker-lifecycle (ADDED-only): F.1 resume ladder prefers the latest holder's own distillation over any earlier generation's document; an un-exhausted latest holder with no document resumes from its transcript instead. - opsx-archive-skill (deliberate MODIFY, not ADDED-only): the Task Completion Check requirement is REPLACED wholesale -- incomplete tasks upgraded from a soft warning to a hard gate (refuse by default, explicit override required, refuse outright non-interactively). Two new ADDED requirements inserted alongside it: Verification Verdict Gate (hard-gates on VERIFY VERDICT: BLOCKED, consuming child #2's evidence file) and Delivery Precondition Check (soft warning on missing/portfolio-deferred ship-log.md). All six specs validated clean (`rasen spec validate`). Staged the six spec subdirectories individually (not the bare rasen/specs/ parent) per the established precise-pathspec discipline; confirmed git status --porcelain -- rasen/specs/ showed exactly these six entries (4 modified, 2 untracked new) before staging, nothing from another session. All 20/20 tasks complete; all 4 artifacts done. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DumoeDss
referenced
this pull request
in DumoeDss/rasen
Jul 9, 2026
…urs resolve from status JSON (WF-3 T1/T4 + WF-9) Closes the externalization-proof subset of WF-3 (path hardcoding) plus WF-9, so archive/sync-specs/office-hours resolve their artifact paths from status JSON rather than assuming a repo-local rasen/ layout. - WF-9: archive-change.ts step 3 (both getters) reads the tasks file via artifactPaths.tasks.existingOutputPaths from status JSON instead of assuming a literal tasks.md, matching the key rasen-bulk-archive-change.ts already uses. - WF-3 T1: archive-change.ts step 4 + sync-specs.ts steps 4b/4d (all getters) resolve the main-spec compare via the specs/ sibling of planningHome.changesDir from status JSON, not a literal repo-relative rasen/specs/<capability>/spec.md -- in a registered store this correctly resolves to the store's own specs. - WF-3 T4: office-hours.ts Dual-Write step resolves both write paths (active-change and no-active-change cases) from changeRoot / planningHome.changesDir sibling, completing the WF-2 reader-writer symmetry -- the writer now agrees byte-for-byte with child #5's propose reader. - Parity registry: 6 function + 3 content hash updates for the affected sync-specs/archive-change/office-hours-command families. Alignment decision (b), deliberate scope split: this change ships only the externalization-proof subset (T1/T4 + WF-9). T3 (ephemera / workDir paths) is explicitly deferred to the separate, concurrently running externalize-artifacts-t3-workdir session -- a different portfolio, working on src/core/working-set.ts and the new src/core/change-work.ts. WF-3 closes across two portfolios; this change's ship-log records the split so it isn't lost. "prompt-audit- fixes portfolio complete" does not mean "all of WF-3 landed here." Shipped promptly to win a file-level serialization race: the externalize-artifacts-t3-workdir session has planned read-side edits to archive-change.ts (same file, non-overlapping regions) but had not yet applied them at ship time -- landing first means that session rebases trivially against a small, known diff. Confirmed: only steps 3 and 4 of archive-change.ts touched in each getter; steps 3.5/3.6 (added by child #5) are byte-untouched by this diff. Reviewed CLEAN (first pass): 0 Blocker/0 Major/0 Minor, 1 Trivial informational (tasks.md's own scope-check assertion was stale against the shared working tree, which also shows the t3-workdir session's unrelated working-set.ts/change-work.ts files -- correctly attributed elsewhere, no actual scope breach). Resolution-semantics core-risk check confirmed the specs/-sibling idiom matches the pattern child #5's propose reader already established, not invented fresh. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
DumoeDss
referenced
this pull request
in DumoeDss/rasen
Jul 9, 2026
Moves the completed prompt-audit-fixes-store-paths change (child #6, FINAL child of the prompt-audit-fixes portfolio) to rasen/changes/archive/2026-07-09-prompt-audit-fixes-store-paths/ and syncs its three delta specs into rasen/specs/ (all MODIFIED existing capabilities, ADDED-only appends, no existing content changed): - opsx-archive-skill: archive resolves artifact paths from status JSON (tasks via artifactPaths.tasks.existingOutputPaths, main-spec compare via the specs/ sibling of planningHome.changesDir), matching bulk-archive-change's existing resolution so single and bulk archive agree. - specs-sync-skill: sync-specs resolves the main-spec write target from the planning home instead of a literal repo-relative path, so store-scoped syncs land in the store's specs. - opsx-office-hours-command: office-hours resolves both its active-change and no-active-change write paths from status JSON, matching the same location propose already scans (child #5's WF-2 reader) so producer and consumer agree in store mode. All three specs validated clean (`rasen spec validate`). Staged the three spec subdirectories individually (not the bare rasen/specs/ parent) per the established precise-pathspec discipline; confirmed git status --porcelain -- rasen/specs/ showed exactly these three entries before staging, nothing from another session. All 11/11 tasks complete; all 4 artifacts done. This is the final child of the prompt-audit-fixes portfolio -- see this change's ship-log.md for the two-portfolio WF-3 close-out note (T3 tier is deferred to the separate externalize-artifacts-t3-workdir session). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
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.
Summary
This PR adds a change proposal for implementing an
openspec statuscommand that will provide visibility into the state of OpenSpec changes.What This PR Contains
This is a change proposal only - no implementation yet. The proposal includes:
proposal.md- Explains why we need the status commandtasks.md- Implementation checklist with 7 task groupsdesign.md- Technical architecture and parsing strategyspecs/cli-status/- Future state specificationsProposed Feature
The status command would provide visibility into:
Proposed Output Example
Key Design Decisions
[x],[X],[✓])Next Steps
Once this proposal is approved:
tasks.mdReview Checklist