-
Notifications
You must be signed in to change notification settings - Fork 6.9k
Description
Problem
gstack's artifact filing (~/.gstack/projects/$SLUG/) derives the slug from the current git repo. This assumes project = repo. When a project spans multiple repos, design docs, test plans, and review results have no stable home.
Concrete example
A platform service project spans 4 repos:
- Application service (Go backend + CLI + container image)
- Helm chart for deployment
- Terraform module
- Infrastructure repo (Terraform for environment-specific resources)
One design doc covers the full system. /office-hours produced it, /plan-ceo-review reviewed it, /plan-eng-review reviewed it. All three sessions ran from a working directory that wasn't any of the project repos (skills were vendored locally in an unrelated directory), so the slug resolved to that directory's repo name and all artifacts landed under the wrong project.
When implementation starts across the actual repos, each repo resolves a different slug. No session will find the design doc or review history unless pointed at it by explicit path.
What breaks
/plan-eng-reviewdesign doc check (ls ~/.gstack/projects/$SLUG/*-design-*.md) finds nothing when the slug doesn't match where the doc was filed- Review readiness dashboard (
gstack-review-read) is global (not slug-scoped), so review status works, but test plans and design docs are orphaned /office-hourssaves a design doc under one slug;/plan-eng-reviewin a different repo can't find it
Why this happens
The slug detection chain is:
remote-slug(GitHub remote name)basename $(git rev-parse --show-toplevel)(repo directory name)basename $(pwd)(fallback)
All three are repo-scoped. There's no concept of a project that groups multiple repos.