What I'm proposing
First — thank you for gstack. I've been running it daily and the two ends of the lifecycle are excellent: the thinking side (/office-hours + the CEO/Eng/Design/QA review personas) and the execution side (the sprint / goal-loop conductors taking a spec to a PR).
The spot I keep filling in myself is the middle — turning a raw idea into a structured backlog the execution end can run autonomously. I've built an explicit decomposition ladder for that and have been using it in anger:
/office-hours (first principles)
→ roadmap (sequenced outcomes/milestones)
→ epics (shippable chunks of value)
→ stories (one-PR-sized, with acceptance criteria)
→ sprints (executable batches)
→ gstack sprint/goal-loop executes each story
The one-PR-per-story sizing is what makes the autonomous execution reliable — each unit maps to something the build loop can objectively verify it finished.
The build/review split (the execution leg)
The principle that makes the autonomous side trustworthy: the model that builds is never the model that reviews. Cheap open-weight models (US-hosted via Fireworks) do the building; frontier models gate them adversarially.
| Side |
Role |
Model |
When it runs |
| Build |
Default builder |
MiniMax M3 |
Most lanes — cheapest, teardown-resilient |
| Build |
Orchestrator |
GLM-5.2 |
Hardest lanes (mission stack) |
| Build |
Worker |
Kimi K2.7 Code |
Hardest lanes (mission stack) |
| Build |
Validator |
DeepSeek V4 Pro |
Hardest lanes (mission stack) |
| Review |
Adversarial gate |
Codex + Grok + Claude |
Every lane — non-negotiable on security-sensitive lanes |
(Model names are a mid-2026 snapshot; the roles are the durable part. This whole leg is the dependency-heavy part that I'd keep in a separate repo — see below.)
The ask
I'd rather match your direction than guess at it, so before I send anything: would you want the gstack-native parts of this upstream, or would you prefer I keep it as a linked satellite repo?
I ask because the ladder itself is pure gstack (no new dependencies) and could live upstream cleanly. But the way I run the execution leg adds two other projects — ponytail as a code-quality gate inside the build, and an autonomous build agent (Factory Droid, chosen for its native mission structure and because it serves open-weight models through Fireworks AI — US-based inference, not the vendors' own APIs) running open-weight builders (MiniMax M3, or a GLM-5.2 / Kimi K2.7 Code / DeepSeek V4 Pro mission stack) gated by frontier adversarial reviewers (Codex / Grok / Claude) on the builder ≠ reviewer principle. I would not want to push a hard dependency on someone else's project into your core, so I'm assuming that execution-wiring part stays in a separate repo regardless, and only the dependency-free decomposition ladder is an upstream candidate.
What I can send
- A PR adding the decomposition-ladder skills/flow in gstack's existing style (the dependency-free part).
- A standalone writeup of the full loop + the hard-won gotchas (Windows copy-not-symlink, the Chromium extraction deadlock, the embedding-provider-default trap, the OpenCode persistent-backend gotcha, etc.) that you're welcome to link from the README, or that I'll just host myself.
Happy to do as much or as little of that as fits gstack. If "keep it as a satellite and I'll link it" is the answer, that's totally fine — just let me know which you'd prefer before I open a PR.
What I'm proposing
First — thank you for gstack. I've been running it daily and the two ends of the lifecycle are excellent: the thinking side (
/office-hours+ the CEO/Eng/Design/QA review personas) and the execution side (the sprint / goal-loop conductors taking a spec to a PR).The spot I keep filling in myself is the middle — turning a raw idea into a structured backlog the execution end can run autonomously. I've built an explicit decomposition ladder for that and have been using it in anger:
The one-PR-per-story sizing is what makes the autonomous execution reliable — each unit maps to something the build loop can objectively verify it finished.
The build/review split (the execution leg)
The principle that makes the autonomous side trustworthy: the model that builds is never the model that reviews. Cheap open-weight models (US-hosted via Fireworks) do the building; frontier models gate them adversarially.
(Model names are a mid-2026 snapshot; the roles are the durable part. This whole leg is the dependency-heavy part that I'd keep in a separate repo — see below.)
The ask
I'd rather match your direction than guess at it, so before I send anything: would you want the gstack-native parts of this upstream, or would you prefer I keep it as a linked satellite repo?
I ask because the ladder itself is pure gstack (no new dependencies) and could live upstream cleanly. But the way I run the execution leg adds two other projects — ponytail as a code-quality gate inside the build, and an autonomous build agent (Factory Droid, chosen for its native mission structure and because it serves open-weight models through Fireworks AI — US-based inference, not the vendors' own APIs) running open-weight builders (MiniMax M3, or a GLM-5.2 / Kimi K2.7 Code / DeepSeek V4 Pro mission stack) gated by frontier adversarial reviewers (Codex / Grok / Claude) on the builder ≠ reviewer principle. I would not want to push a hard dependency on someone else's project into your core, so I'm assuming that execution-wiring part stays in a separate repo regardless, and only the dependency-free decomposition ladder is an upstream candidate.
What I can send
Happy to do as much or as little of that as fits gstack. If "keep it as a satellite and I'll link it" is the answer, that's totally fine — just let me know which you'd prefer before I open a PR.