cmoriarty/braid
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases Packages 1 Wiki Activity Actions

A quick-fix pipeline: branch, tests and a PR, without an OpenSpec change #55

New issue
Closed
opened 2026-09-26 16:57:07 -04:00 by cmoriarty · 1 comment
cmoriarty commented 2026-09-26 16:57:07 -04:00
Owner
Copy link

Problem

Every built-in pipeline that writes code starts with openspec.new-change → propose → validate. minimalist and git-flow-hotfix are the lightest, and they still write a proposal, specs, a design and tasks. A trivial fix (a UI tweak, a typo, a one-line bug) pays for the whole OpenSpec process, and when done by hand these skip OpenSpec anyway.

The nodes after propose also assume a change exists: openspec.apply works through the change's tasks.md, the test-suite and summary prompts look up the change id, and landing archives the change. So removing the propose nodes from a pipeline is not enough.

Proposal

A built-in quick-fix pipeline that keeps the engineering discipline and drops the spec:

git.clone → script.brief → script.agents-md
  → fix.implement      agent: the brief → code + unit tests, on the work branch
  → test.unit          always
  → test.e2e           when ui_changed
  → git.commit.feature
  → fix.summarize      agent: PR description from the brief and the diff
  → git.pr.open → human.merge-pr → git.pr.merge

No archive steps: there is no change.

  • Implement from the brief. A new prompt for fix.implement that works from the issue text instead of tasks.md, and is told to add or update tests alongside the fix.
  • Tests and summary without a change. The test-suite and summary prompts (and the PR-open script, if it assumes a change) fall back to the brief and the diff when the run has no change.
  • Chosen explicitly. In the New Run picker like any pipeline, and from Forgejo: an issue labelled quick-fix starts on this pipeline when the run label is applied.
  • Spec drift is flagged, not silently absorbed. A quick fix does not update openspec/specs. The PR summary says so, and notes when the diff touches behaviour an existing spec describes, as a prompt to reconsider.

Out of scope

  • Automatic triage (an agent deciding whether a change needs a spec). Who decides is the operator's call.
  • A step that edits CI configuration. The merge gate already shows the pull request's checks.

Done when

  • A run on quick-fix goes from brief to an open pull request with tests, with no openspec/changes directory created.
  • An issue labelled quick-fix starts on that pipeline.
  • Existing pipelines behave exactly as before.
## Problem Every built-in pipeline that writes code starts with `openspec.new-change` → propose → validate. `minimalist` and `git-flow-hotfix` are the lightest, and they still write a proposal, specs, a design and tasks. A trivial fix (a UI tweak, a typo, a one-line bug) pays for the whole OpenSpec process, and when done by hand these skip OpenSpec anyway. The nodes after propose also assume a change exists: `openspec.apply` works through the change's `tasks.md`, the test-suite and summary prompts look up the change id, and landing archives the change. So removing the propose nodes from a pipeline is not enough. ## Proposal A built-in **`quick-fix`** pipeline that keeps the engineering discipline and drops the spec: ``` git.clone → script.brief → script.agents-md → fix.implement agent: the brief → code + unit tests, on the work branch → test.unit always → test.e2e when ui_changed → git.commit.feature → fix.summarize agent: PR description from the brief and the diff → git.pr.open → human.merge-pr → git.pr.merge ``` No archive steps: there is no change. - **Implement from the brief.** A new prompt for `fix.implement` that works from the issue text instead of `tasks.md`, and is told to add or update tests alongside the fix. - **Tests and summary without a change.** The test-suite and summary prompts (and the PR-open script, if it assumes a change) fall back to the brief and the diff when the run has no change. - **Chosen explicitly.** In the New Run picker like any pipeline, and from Forgejo: an issue labelled `quick-fix` starts on this pipeline when the run label is applied. - **Spec drift is flagged, not silently absorbed.** A quick fix does not update `openspec/specs`. The PR summary says so, and notes when the diff touches behaviour an existing spec describes, as a prompt to reconsider. ## Out of scope - Automatic triage (an agent deciding whether a change needs a spec). Who decides is the operator's call. - A step that edits CI configuration. The merge gate already shows the pull request's checks. ## Done when - A run on `quick-fix` goes from brief to an open pull request with tests, with no `openspec/changes` directory created. - An issue labelled `quick-fix` starts on that pipeline. - Existing pipelines behave exactly as before.
cmoriarty commented 2026-09-26 17:10:04 -04:00
Author
Owner
Copy link

Shipped in #56 (d06e1d3) and archived as openspec/changes/archive/2026-09-26-quick-fix-pipeline.

  • quick-fix built-in pipeline: brief → fix.implement (the fix and tests that fail without it, plus a note in .osf/fix.md) → unit tests → browser tests when UI files changed → commit → summary → pull request → merge gate → merge. No OpenSpec change is created and there is no archive step.
  • The fix step must change code: it succeeds only when .osf/fix.md exists and the new worktree-changed check sees a change outside .osf/.
  • Tests and summary work without a change, from the brief, the fix note and the diff. They never borrow an unrelated in-flight change from openspec/changes/. The PR summary ends with a No spec updated bullet naming any specified capability the diff may touch.
  • Choosing it: the New Run picker, or label an issue osf:quick-fix.
  • Existing pipelines are unchanged.
Shipped in #56 (d06e1d3) and archived as `openspec/changes/archive/2026-09-26-quick-fix-pipeline`. - **`quick-fix` built-in pipeline:** brief → `fix.implement` (the fix and tests that fail without it, plus a note in `.osf/fix.md`) → unit tests → browser tests when UI files changed → commit → summary → pull request → merge gate → merge. No OpenSpec change is created and there is no archive step. - **The fix step must change code:** it succeeds only when `.osf/fix.md` exists and the new `worktree-changed` check sees a change outside `.osf/`. - **Tests and summary work without a change,** from the brief, the fix note and the diff. They never borrow an unrelated in-flight change from `openspec/changes/`. The PR summary ends with a **No spec updated** bullet naming any specified capability the diff may touch. - **Choosing it:** the New Run picker, or label an issue `osf:quick-fix`. - Existing pipelines are unchanged.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
archive/prefect-kestra-experiments
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cmoriarty/braid#55
No description provided.