Development is a loop,
not a line.

The loop

Every loop turn starts with an intent — a statement of aim. Analysis turns the aim into evidence. Evidence yields proposals. Promotion turns the chosen proposal into committed delivery work. Review closes the cycle: it sends work back for fixes, reopens plans that didn't survive contact with reality, and seeds the next intent from what was learned. Upstream of it all, signals carry everything the outside world tells you into the loop's front door.

The return edges are the point. A one-way pipeline treats rework as failure; the loop treats it as the normal mechanics of getting something right. Fix loops route review findings back to implementation. Re-spec loops reopen the plan when the idea itself needs work. And when a loop completes, its learnings become the input to the next one — the system never stops at "done". Each completed turn is counted as a numbered loop iteration and closed with a summary: score delta, epics shipped, learnings seeded, spend.

The North Star constellation

A project's aim is not a single document. Stella Loop models it as a constellation of North Star documents, each a set of tenets typed by concern — product, design, engineering, agent experience, or whatever composition fits your team. The constellation is not passive documentation: it is a live, versioned product object. Analyzers score against pinned document versions, proposals cite it, and prioritization is justified by it.

Documents carry weights, and per-document scores roll into one composite number worth improving. When two documents pull in opposite directions, that conflict is recorded as a tension to acknowledge and resolve — never silently averaged away.

Shared project context

The constellation, reports, specs, and dependencies form one body of context that every participant — human or agent — reads from the same place. Nobody starts a task by reconstructing what the team already knows: stella context show TSK-214 returns the intent, the North Star lines that motivated it, the spec, the dependencies, and the gates.

Work provenance

Every epic traces back through its proposal to the report that motivated it, the intent that started the loop — and, when the work began life as a signal, all the way to the original GitHub issue or Slack thread. The chain is short, legible, and mandatory:

SIG-238 → INT-31 → RPT-41 → PRP-19 → EPC-12 → TSK-214

When someone asks "why are we building this?", the answer is a chain of records, not an archaeology project.

Signals

A signal is an uninterpreted observation captured upstream of the loop — a bug report, a customer email, a Sentry alert, a teammate's Slack message, a ten-second thought. Capture is deliberately frictionless: a global keyboard chord in the app, a one-line CLI command, or a connector that ingests GitHub Issues, Slack messages, Sentry alerts, inbound email, and signed webhooks automatically.

Triage gives each signal its altitude: seed a draft intent, attach as evidence to work already in flight, merge as a duplicate — accumulating a demand count — or dismiss with a reason. Nothing is silently lost or rewritten. Merged duplicates build demand clusters, and a built-in demand analyzer turns that corpus into scored findings — so "eleven people asked for CSV export" is evidence, not folklore. When the work that resolves a signal finally ships, Stella Loop can post one resolution notice back to the source thread: the loop answers the person who asked.

Intents

Intents come in two archetypes. A directed intent names the work — "add feature X" — and routes to targeted analysis such as feature pre-scoping, which maps what already exists before anything is built. A North Star-driven intent names only the aim — "move us toward the constellation" — and fans out a broad battery of analyzers, letting the evidence decide what gets proposed.

Intents can be standing: re-fire triggers — manual, on a schedule, after each merge, or when a score drops — re-arm the intent after every run. That is what makes the outer loop continuous rather than manually cranked. Either way, the upstream stages run: even a hand-initiated feature gets pre-scoping by default, so commitment always follows evidence.

Analysis

Each project carries a registry of analyzers — units of analysis that examine the product and produce a report. Some are agentic: a UX walkthrough agent uses the application like a user and writes an experience report. Some are deterministic: static analysis, metrics, checks. Both kinds live under one manifest, run in parallel, and can be authored three ways — config files in your repo, an in-app builder, or a shared registry where the built-in suite ships: UX walkthrough, code quality, security review, feature pre-scoping, gap analysis, demand signals, and North Star satisfaction.

Structured reports

A report is evidence, not prose: findings with severity, area, and code references, per-area scores, and clear paths to action. Reports are project-level assets — reusable across many proposals and epics rather than trapped inside a single ticket.

Scores and the quality trajectory

Analyzers score what they examine on a 0–100 scale, and scores roll up to a project-level picture: the composite North Star satisfaction score, per-area scores, per-document scores. Comparability is structural: every score permanently records the analyzer version, rubric version, and model that produced it, and deltas are only drawn against same-rubric predecessors. Scores are integers, and deltas appear only where two runs are compared — measurement is evidence of improvement, not decoration.

A note on honesty: any metric a system optimizes can be gamed. Stella Loop treats scores as instruments, not goals — agentic score submissions must explain themselves, sampled scores are audited by an independent re-score, and every number is inspectable down to the findings that produced it.

The proposal pool

Between analysis and delivery sits a deliberate half-step. Proposals derived from reports land in a project-level pool, ordered by priority band, structured by dependencies, with every proposal permanently anchored to the report that motivated it. The pool exists because planning is the expensive stage — prioritization must happen before the costly work, not after.

Promotion is the commitment point. Promoting out of the pool creates an epic — that is the moment the team decides the work is worth spending on, it passes a human-approval gate by default, and there is deliberately no other way to create an epic in the UI, the API, or the CLI.

Sibling sets

Alternative proposals aimed at the same problem group into a sibling set. The set names the problem worth solving; the proposals are competing answers to it. Independent proposals — distinct problems that may all need doing — stand as sets of one. The set is the unit the pool orders, blocks, prunes, and promotes.

Candidate tournaments

When a decision deserves stronger evidence than a debate, promote the whole sibling set as a tournament: each proposal becomes a candidate with its own spec and its own branch-set, the candidates are implemented in parallel, and review selects the winner on results. Losing candidates are archived with structured learnings — pruned, not wasted. The engine recommends a tournament only when three signals hold: the approaches genuinely diverge, the problem is high-stakes, and the budget has headroom.

Epics

An epic is the committed unit of delivery. It owns the spec, the tasks, the implementation, and the review — and it arrives with its full provenance attached: signal, intent, reports, proposal. Its stage pipeline (Plan → Implement → Review → Done, with the fix and re-spec loop-backs) is an explicit state machine enforced server-side — never a status field someone forgot to update. Epics can span multiple repositories, with one coordinated branch per repo merged as a single change set.

Specs and tasks

Each candidate is turned into a spec by a pluggable spec tool — OpenSpec by default — then decomposed into implementable tasks with explicit dependencies. Planning is where the strongest models earn their cost; the spec is the contract every task traces back to, and approving it is a checkpoint of its own.

Model tiers and budgets

Different stages warrant different strength. Stages request a tier — frontier, standard, or economy — and the engine resolves the model: planning defaults to frontier, implementation to standard per task, review to a panel. Budgets cap spend per project period, per loop iteration, and per tournament, with warning thresholds and hard stops. Costs are visible per run and roll up per loop — and a budget stop is a visible stop, never a silent downgrade.

Gates and the autonomy dial

Human checkpoints are first-class objects in the pipeline, not settings buried in an admin page. Every consequential transition passes a named gate — intent activation, promotion, spec approval, review sign-off, merge — and each gate can require approval, approve by default after an objection window, or run autonomously with an audit trail. Out of the box, the two hard gates sit exactly where money and irreversibility live: epic.promote and epic.merge require a human's yes. A project-level dial — supervised, balanced, autonomous — sets every gate at once, so oversight is a dial you turn as trust grows, not a redesign.

Humans and agents, one model

Agents are not a feature bolted onto a human tool. Humans work through a fast, keyboard-first interface; agents work through the stella CLI, the public API, and a generated MCP server. Both act on the same domain model — the same intents, specs, tasks, and gates. Parity is not a policy but an artifact: one capability map generates the API routes, the CLI command tree, and the MCP tools, and CI fails when any surface is missing. If a human can do it in the UI, an agent can do it from stella --help.

Review and improvement

Implemented work is reviewed by a configurable panel — reviewer agents with explicit lenses like correctness, security, spec fidelity, and North Star alignment, plus any humans you add. Findings synthesize into a recommendation by deterministic rules; the decision drives one of three modeled edges: a fix loop back to implementation, a re-spec escalation back to the plan, or acceptance toward merge. In a tournament, review selects the winning candidate on evidence. After the ordered merge, post-merge analysis compares the scores that matter, learnings land in the record, resolution notices answer the signals that started it — and the findings seed the next intent. The loop begins again.

Opinionated about the loop. Open about the tools.

The loop shape is the product's opinion. The tools inside each stage are yours: bring your spec system, your analyzers, your model providers, your coding agents, and your version-control workflow — git by default, Jujutsu supported, coordinated through a GitHub App across one repository or many. Stella Loop takes the place of the issue tracker — it does not take the place of your stack.

Ready for the operational detail? The documentation covers every concept here in depth, from getting started to the API and CLI.