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

Build out the New Project process #100

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

RIght now all you can do is type a description, so by default all you can do if one-shot the whole project. That is useful for some scenarios, but I think the more common one is that the first step is to do planning. As part of the New Project wizard, the user could be asked if they would like for braid to first create a plan from the description. Then they could review the plan, and choose whether that plan should be turned into Forgejo issues/projects, and the backend would create a plan, and it should know the first task it will offer to start once the plan is done, and offer to start it once the plan is done (but also let the user select a different first issue to implement). The plan could also be tracked in a markdown file on the project. Something braid could read and find tasks to implement, and our pipeline has a step to ensure it is kept up to date as the project progresses.

I'd also like to research a sensible planning philosophy so the user isn't overwhelmed with hundreds of Issues, or a massive planning document. The resulting plan should be designed with a human in mind, it should be easy to understand quickly, and not too text dense.

Perhaps the user could choose from an interactive plan, where the model would ask it questions, or an automated one with no questions.

In the settings there should an option added to specify a different backend service for planning. Perhaps a checkbox for "use the same for planning" could also be added, and have it checked by default.

RIght now all you can do is type a description, so by default all you can do if one-shot the whole project. That is useful for some scenarios, but I think the more common one is that the first step is to do planning. As part of the New Project wizard, the user could be asked if they would like for braid to first create a plan from the description. Then they could review the plan, and choose whether that plan should be turned into Forgejo issues/projects, and the backend would create a plan, and it should know the first task it will offer to start once the plan is done, and offer to start it once the plan is done (but also let the user select a different first issue to implement). The plan could also be tracked in a markdown file on the project. Something braid could read and find tasks to implement, and our pipeline has a step to ensure it is kept up to date as the project progresses. I'd also like to research a sensible planning philosophy so the user isn't overwhelmed with hundreds of Issues, or a massive planning document. The resulting plan should be designed with a human in mind, it should be easy to understand quickly, and not too text dense. Perhaps the user could choose from an interactive plan, where the model would ask it questions, or an automated one with no questions. In the settings there should an option added to specify a different backend service for planning. Perhaps a checkbox for "use the same for planning" could also be added, and have it checked by default.
cmoriarty commented 2026-09-28 00:02:38 -04:00
Author
Owner
Copy link

Shipped in four OpenSpec changes, all archived on main.

1. new-project-plan: plan first

  • The New Run wizard asks a New Project: Plan first, with questions, Plan first, without questions, or Build it in one run. The pipeline step then becomes "Pipeline for the work".
  • A missing repository is created when the run starts: private on Forgejo, or git init for a local path. An empty repository gets a first commit.
  • The new plan pipeline plans with OpenSpec:
    • PLAN.md is a one-screen roadmap;
    • each item in the Now milestone is a proposed OpenSpec change with its proposal.md;
    • the project context goes in openspec/config.yaml.
  • The plan's shape is checked, not just asked for: a goal of at most 60 words, 3–7 Now items starting with a walking skeleton, one line for Next, at most four Later milestones, and at most 60 lines.
  • You review PLAN.md at a gate and can have it revised up to twice.
  • If the work pipeline doesn't use OpenSpec, openspec/ is removed before the pull request, so only PLAN.md lands.

2. plan-to-forgejo: issues and the first task

  • An optional gate files the Now items as issues, in Now and Next milestones, with each proposal as the issue body. PLAN.md gets the issue numbers.
  • Forgejo has no Projects API, so milestones are the grouping.
  • Once the plan is merged, a gate offers to start the first item or any other. It starts the run on the work pipeline.
  • A run on a planned item continues that item's OpenSpec change instead of creating a new one.

3. planning-backend: a separate planning backend

  • Settings → Backend has Use the same for planning, checked by default.
  • Unchecked, you get the planning backend's kind, URL (with its own Test connection), model, context window and key file.
  • The plan's write and revise steps use it; every other step keeps the main backend.

4. plan-stays-current: PLAN.md stays current

  • script.plan-tick runs before the pull request in every implementing pipeline.
  • It ticks the Now item the run carries out, matched by change id, then issue, then brief, in the run's own pull request.
  • It says when the Now milestone is done.

Tested: the full lane with the @live specs, and the real console on the local demo stack. It also ran end to end on production in cmoriarty/braid-plan-test2:

  • the repository was created;
  • the real model wrote the plan;
  • five issues were filed in milestones;
  • the plan PR (#6) was merged;
  • the start gate began a run on issue #1, which continued the planned change add-score-skeleton.

Deployment note: the osfd token needs user: Read and write for a New Project to create its repository. deploy/README.md now says so.

Shipped in four OpenSpec changes, all archived on `main`. **1. `new-project-plan`: plan first** - The New Run wizard asks a New Project: *Plan first, with questions*, *Plan first, without questions*, or *Build it in one run*. The pipeline step then becomes "Pipeline for the work". - A missing repository is created when the run starts: private on Forgejo, or `git init` for a local path. An empty repository gets a first commit. - The new `plan` pipeline plans with OpenSpec: - `PLAN.md` is a one-screen roadmap; - each item in the Now milestone is a proposed OpenSpec change with its `proposal.md`; - the project context goes in `openspec/config.yaml`. - The plan's shape is checked, not just asked for: a goal of at most 60 words, 3–7 Now items starting with a walking skeleton, one line for Next, at most four Later milestones, and at most 60 lines. - You review `PLAN.md` at a gate and can have it revised up to twice. - If the work pipeline doesn't use OpenSpec, `openspec/` is removed before the pull request, so only `PLAN.md` lands. **2. `plan-to-forgejo`: issues and the first task** - An optional gate files the Now items as issues, in Now and Next milestones, with each proposal as the issue body. `PLAN.md` gets the issue numbers. - Forgejo has no Projects API, so milestones are the grouping. - Once the plan is merged, a gate offers to start the first item or any other. It starts the run on the work pipeline. - A run on a planned item continues that item's OpenSpec change instead of creating a new one. **3. `planning-backend`: a separate planning backend** - Settings → Backend has **Use the same for planning**, checked by default. - Unchecked, you get the planning backend's kind, URL (with its own Test connection), model, context window and key file. - The plan's write and revise steps use it; every other step keeps the main backend. **4. `plan-stays-current`: `PLAN.md` stays current** - `script.plan-tick` runs before the pull request in every implementing pipeline. - It ticks the Now item the run carries out, matched by change id, then issue, then brief, in the run's own pull request. - It says when the Now milestone is done. **Tested:** the full lane with the `@live` specs, and the real console on the local demo stack. It also ran end to end on production in `cmoriarty/braid-plan-test2`: - the repository was created; - the real model wrote the plan; - five issues were filed in milestones; - the plan PR (#6) was merged; - the start gate began a run on issue #1, which continued the planned change `add-score-skeleton`. **Deployment note:** the osfd token needs **user: Read and write** for a New Project to create its repository. `deploy/README.md` now says so.
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#100
No description provided.