fix: show changes created by OpenSpec 1.0+, and what each one is waiting for (0.2.0)#2
Merged
Merged
Conversation
…ing for A change was only recognised if it contained proposal.md. Current OpenSpec writes .openspec.yaml when the change is created and the proposal only once an agent drafts it — so every freshly created change was missing from the board until someone wrote a proposal, which is the exact moment you most want to see it. Verified against OpenSpec 1.6: `openspec new change x` produces a directory with nothing but the marker. Either marker now identifies a change. Then the board says more than "these files exist". Each change reports its artifact chain — proposal, design, specs, tasks — as complete, ready (dependencies met, nothing blocking) or blocked, with the artifacts it waits for. The vocabulary and the dependency graph match `openspec status --change <name>` output field for field, but everything is derived from the files on disk, so no OpenSpec install is needed in the repos being watched and it stays read-only. Cards mark the next actionable artifact instead of hiding what has not been written yet. Housekeeping the release needed: - CI on push and pull request (frontend build, cargo test, clippy). Nothing verified commits before, which is how 14 clippy warnings and a broken parser assumption accumulated unnoticed. Warnings fixed. - release.yml publishes archives from a v* tag for four targets, adding macOS Intel. The four dispatch-only workflows it replaces built the same binaries but only uploaded them as build artifacts, so cutting a release meant downloading and re-uploading by hand. A workflow_dispatch entry point is kept for builds without a tag. - Removed `readyForReview` from the Change type: declared in the frontend contract, never sent by the backend, never read by any component. - Removed a file literally named `--config` — a shell mishap committed a copy of the example config under that name. - CHANGELOG.md, and VERSION/Cargo.toml stamped 0.2.0.
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.
The bug
A change was only recognised if it contained
proposal.md. Current OpenSpec writes.openspec.yamlwhen the change is created, and the proposal only once an agent drafts it — so every freshly created change was missing from the board until someone wrote a proposal, which is the exact moment you most want to see it.Verified against OpenSpec 1.6:
Either marker now identifies a change, so the pre-1.0 layout keeps working too.
What the board says now
Each change reports its artifact chain —
proposal,design,specs,tasks— as complete, ready (dependencies met, nothing blocking it) or blocked, with the artifacts it is waiting for:Vocabulary and dependency graph match
openspec status --change <name>field for field (diffed against the real CLI), but everything is derived from the files on disk — so no OpenSpec install is needed in the repos being watched, and the dashboard stays read-only. Cards mark the next actionable artifact instead of only showing what already exists.Housekeeping the release needed
cargo test,cargo clippy -D warnings). Nothing verified commits before this, which is how 14 clippy warnings and a broken parser assumption accumulated unnoticed. Warnings fixed.release.ymlpublishes archives from av*tag for four targets (adds macOS Intel). The four dispatch-only workflows it replaces built the same binaries but only uploaded them as build artifacts, so cutting a release meant downloading and re-uploading by hand. Aworkflow_dispatchentry point is kept.readyForReviewfrom theChangetype — declared in the frontend contract, never sent by the backend, never read by any component.--config: a shell mishap committed a copy of the example config under that name.CHANGELOG.mdadded;VERSIONandCargo.tomlstamped 0.2.0.Verification
cargo test— 8 passed (5 new: artifact chain at each stage, schema reading, marker-only change visibility)cargo clippy— 0 warningsvitest— 4 passed;npm run buildcleanopenspec status --change <name> --json