Instruction file imported from earthboundtrev/ducking_gravity (
.cursor/rules/ticket-lifecycle-loop.mdc). Copyright stays with the author.
Ticket pipeline (pointer)
Active GitHub issue #N and/or open PR work follows a fixed stage order. Track a pointer to the current stage. Advance forward only when that stage passes. Any code fix rewinds the pointer to BUGBOT (then move forward again).
Adapted from SmartAstro (earthboundtrev/astro) for this marketing-site repo (GitHub).
Stages (in order)
IMPLEMENT → BUGBOT → TESTS → ARCHITECT → DEPLOY
| Stage | What happens | Advance when |
|---|---|---|
| IMPLEMENT | Ship code/docs for AC, review feedback, or CI fixes | Chunk ready for review → BUGBOT |
| BUGBOT | Separate bugbot Task (review-bugbot) — never self-review as Bugbot |
Clean on current diff → TESTS |
| TESTS | tests/*.test.js (prefer issue refs / AC mapping); node --test / npm test for touched areas |
Pass → ARCHITECT |
| ARCHITECT | Separate Architect Task — sync contract, layering, merge-ready (.cursor/rules/duckinggravity-architect.mdc) |
Merge-ready → DEPLOY |
| DEPLOY | Validate, push, PR with Closes #N; watch checks; after human merge: verify issue #N CLOSED, delete local ticket branch |
Human merge/sign-off + issue closed + local cleanup → exit |
Separate agents / models (mandatory)
Implementer, Bugbot, and Architect must not be the same review perspective. Different roles exist so a second set of eyes catches bugs the author missed.
Why the model slugs changed (aligned with SmartAstro 8/18/2026): Cursor Grok 4.6 High is far cheaper per token than Opus or Sonnet. Implement was already composer-2.5-fast. Checks were the expensive leak — Bugbot/Architect often omitted model (a costlier tool default) or fell through to Sonnet/Opus on every rewind. This studio’s Cursor budget is effectively zero, so routine reviews must not burn premium tokens. Same split of perspectives; cheaper check model. Full cost chains: .cursor/rules/subagent-watchdog.mdc. Prefer local Tasks: .cursor/rules/prefer-local-agents.mdc.
| Role | How it must run | Primary model | Comparable fallback(s) |
|---|---|---|---|
| IMPLEMENT | Parent and/or implement Task | composer-2.5-fast |
cursor-grok-4.5-high-fast → omit / parent |
| BUGBOT | Always a separate bugbot Task — never “I reviewed my own diff as Bugbot” |
cursor-grok-4.6-high-fast |
cursor-grok-4.5-high-fast → omit |
| ARCHITECT | Always a separate generalPurpose Task as Ducking Gravity Architect — never implementer self-certify |
cursor-grok-4.6-high-fast |
cursor-grok-4.5-high-fast → omit |
Hard rules
- Do not skip Bugbot or Architect by self-certifying (except watchdog soft-fail after comparable chain exhausted —
.cursor/rules/subagent-watchdog.mdc). - Implement is cheap: dedicated implement Tasks use
composer-2.5-fast. Do not spend Opus, Sonnet, or Grok 4.6 High on routine IMPLEMENT. - Checks are Grok 4.6 High: Bugbot, Architect, and security-review launch with
model: "cursor-grok-4.6-high-fast". Do not omitmodelon those Tasks (omitting often bills a costlier default). Do not use Opus/Sonnet for routine checks unless the user explicitly names that model. - After any code fix, rewind to BUGBOT and launch a fresh Bugbot on the new diff.
- On outage/stuck, walk that role’s comparable chain before soft-fail — checks stay in the Grok High family; do not promote them to Opus/Sonnet, and do not demote them to Composer Fast.
- Stay local by default. Omit Task
environmentor set"local". Cloud is a cost spike — never launch it without an explicit cost warning and current-message cost acceptance. Not an outage fallback..cursor/rules/prefer-local-agents.mdc.
Rationale: Composer Fast writes the diff; a separate Grok 4.6 High Task reviews it. Same coverage split, far lower token spend than Sonnet/Opus on every check.
Rewind rules (mandatory)
| Situation | Pointer moves to |
|---|---|
| Bugbot reports findings | Stay BUGBOT — fix, re-run until clean |
| Tests fail or test-driven code changes | BUGBOT |
| Architect reports blockers | BUGBOT — fix → Bugbot → Tests → Architect |
| PR/CI/human review needs code changes | IMPLEMENT — then BUGBOT |
Post-merge / Architect-skip backfill
If release-related work already landed on main without a distinct Architect gate (or the human asks to put a shipped fix through the pipeline):
- Treat merged code as IMPLEMENT done. Pointer starts at
BUGBOT. - Create GitHub issue
#Nif missing (.cursor/rules/github-new-ticket.mdc). - Open remediation branch
fix/architect-backfill-{N}only if reviews produce fixes; otherwise review in place. - Review scope: if branch vs
mainis empty, use Bugbot/Architect withDiff: natural languageand a Change Description of the shipped paths/commits (e.g.261ca6e). - Cycle: Bugbot clean → TESTS → ARCHITECT → DEPLOY (sign-off and/or remediation PR with
Closes #N). - Close issue
#Nwhen the gate completes (even if no code changes).
Bug-class that must get a regression test
Schedule/popup/availability behavior (date windows, hasEnded, removedScheduleIds, dropdown rendering) must include a regression test. These look fine today and break tomorrow.
Exit (human sign-off + issue closed)
- Human approves merge or sign-off-only backfill.
- Verify GitHub issue
#Nis CLOSED (gh issue view {N}). - Delete local feature/remediation branch;
git fetch --prune.
Session resume
- Sync git + read issue/PR (
gh issue view/gh pr view). - If branch diff changed since last clean Bugbot → pointer BUGBOT.
- Report:
Pipeline pointer: <STAGE>.
Response format (active ticket)
Pipeline: IMPLEMENT | BUGBOT | TESTS | ARCHITECT | DEPLOY — Bugbot / tests / architect / deploy / issue open|closed / next stage.