Skip to content

feat: add status command change proposal - #5

Merged
TabishB merged 2 commits into
mainfrom
add-status-command
Aug 6, 2025
Merged

feat: add status command change proposal#5
TabishB merged 2 commits into
mainfrom
add-status-command

Conversation

@TabishB

@TabishB TabishB commented Aug 6, 2025

Copy link
Copy Markdown
Contributor

Summary

This PR adds a change proposal for implementing an openspec status command 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 command
  • tasks.md - Implementation checklist with 7 task groups
  • design.md - Technical architecture and parsing strategy
  • specs/cli-status/ - Future state specifications

Proposed Feature

The status command would provide visibility into:

  • Changes ready to archive (all tasks complete)
  • Changes in progress (some tasks incomplete)
  • Recently archived changes

Proposed Output Example

OpenSpec Status Report
═══════════════════════

Ready to Archive (2):
  ✓ feature-auth           15/15 tasks   3 days old
  ✓ fix-payment-bug        8/8 tasks     1 day old

In Progress (3):
  ⚠ add-user-profile       12/20 tasks   2 days old
  ⚠ refactor-api          3/10 tasks    5 days old

Key Design Decisions

  • Robust task parsing: Would handle multiple checkbox formats ([x], [X], [✓])
  • Context-aware: Would skip false positives in code blocks
  • Multiple output formats: Summary, detailed, and JSON views
  • Workflow integration: Complements the archive command proposal

Next Steps

Once this proposal is approved:

  1. Implementation will follow the tasks outlined in tasks.md
  2. The status command will be built alongside or before the archive command
  3. Both commands will share task parsing utilities

Review Checklist

  • Review the proposed command interface
  • Check if the task parsing strategy is robust enough
  • Validate the proposed output formats
  • Confirm the workflow integration makes sense

@TabishB
TabishB merged commit bf9b148 into main Aug 6, 2025
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>
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.

1 participant