Planning — Phase 1 not started

Every new project, launched the same reliable way.

Foundry turns a spec doc — or a work-in-progress repo — into its own isolated Todoist project, an MVP build loop, and eventually its own staging deploy pipeline. No shared state, ever.

Read the PRD See the roadmap

foundry-mvp-gate — 2 of 3

Dashboarddone

Core featurein progress

Manifest

One file every skill reads, so nothing touches the wrong project.

Every Foundry-tracked project gets a manifest — slug, Todoist project id, repo, domains, MVP checklist status. Every foundry-* skill reads it instead of guessing. It's the single mechanism that keeps a skill from ever acting on a project it wasn't meant for.

{
"slug": "lodgii",
"todoist_project_id": "6hCqQ3f7…",
"repo": "github.com/alinexblu/Lodgii",
"domains": { "staging": "lodgii-staging.trgmproject.com" },
"mvp_status": "in_progress"
}

Dashboard

Core feature — in progress

foundry-mvp-gate: not yet passed — staging deploy withheld

MVP gate

Nothing gets deployed until the MVP actually works.

Login, dashboard, one real feature — or whatever the spec defines as MVP — gets built before any deploy infrastructure is touched. The moment the gate passes, foundry-deploy-staging spins up automatically. MVP2 and Future tasks keep moving in the background either way.

Isolation

Every project gets its own everything.

Own Todoist project, own repo, own VPS subdomain, own secrets, own scheduled routine — namespaced by slug from the start. Two Foundry projects, or a Foundry project and the existing Aura setup, should never be able to collide.

todoist project repo <slug>-staging.domain <SLUG>_PROD_* scheduled routine

The failure mode this is designed against: an Aura-tuned skill quietly reusing Aura's Todoist board names or VPS paths on a brand-new project. Foundry is a fully separate skill family so that can't happen — even where it means duplicating logic.

Roadmap

Five phases, locked in from the 2026-08-22 planning session.

Nothing below has started — Phase 1 is blocked on a handful of open decisions first.

●

Now — open decisions

In progress

Manifest location, MVP definition source, routine cadence, single-vs-concurrent-project support. Naming is resolved — "Foundry."

Phase 1 — spec to tasks

Prove out spec/repo → isolated Todoist project with a prioritized MVP / MVP2 / Future breakdown. No code touched yet.

foundry-init · foundry-spec-to-tasks

Phase 2 — build loop

Later

Run manually against one MVP task to confirm the worktree/test/evidence loop works standalone.

foundry-build-task

Phase 3 — MVP gate + staging

Later

First full spec → MVP → live staging site run, end to end.

foundry-mvp-gate · foundry-deploy-staging

Phase 4 — automate the loop

Later

A new project behaves like Aura's setup — recurring pickup and review, on its own schedule.

foundry-routine-setup · foundry-review

Phase 5 — production

Later

Added last, on purpose. Always a separate, explicitly human-confirmed step — never auto-chained.

foundry-deploy-prod

Every new project, launched the same reliable way.

One file every skill reads, so nothing touches the wrong project.

Nothing gets deployed until the MVP actually works.

Every project gets its own everything.

Five phases, locked in from the 2026-08-22 planning session.

Now — open decisions

Phase 1 — spec to tasks

Phase 2 — build loop

Phase 3 — MVP gate + staging

Phase 4 — automate the loop

Phase 5 — production

Production is never automatic.