Development is a loop,
not a line.

The loop

Every loop 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.

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".

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, or whatever composition fits your team. The constellation is not passive documentation: it is a live input. Analyzers evaluate the product against it, proposals cite it, and prioritization is justified by it.

Because documents are typed, scores can target subsets of the constellation: a design-focused analyzer evaluates against the design North Stars, while the composite North Star alignment rolls per-document scores into one number worth improving.

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.

Work provenance

Every epic traces back through its proposal to the report that motivated it and the intent that started the loop. When someone asks "why are we building this?", the answer is a chain of records, not an archaeology project.

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 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.

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. Analyzers run in parallel, and the registry is pluggable, so the tools your team already trusts become part of the loop.

Structured reports

A report is evidence, not prose: findings broken down by area, optionally scored, with 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, and scores roll up to a project-level picture: North Star alignment, user experience, maintainability, security. Scores are integers, and deltas only appear 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 — they justify work, reveal drift, and prove direction, and they are always inspectable down to the findings that produced them.

The proposal pool

Between analysis and delivery sits a deliberate half-step. Proposals derived from reports land in a project-level pool, structured by dependencies and ordered by priority. The pool exists because planning is the expensive stage — prioritization must happen before the costly work, not after.

Promotion is the commitment point. Promoting a proposal out of the pool creates an epic — that is the moment the team decides the work is worth spending on, and the natural place for a human approval gate.

Opportunities

Alternative proposals aimed at the same problem group into an opportunity. The opportunity names the problem worth solving; the proposals are competing answers to it. Independent proposals — distinct problems that may all need doing — stand on their own.

Candidate tournaments

When a decision deserves stronger evidence than a debate, promote the whole opportunity as a tournament: each proposal becomes a candidate with its own spec and branch, the candidates are implemented in parallel, and review selects the winner on results. Losing candidates are archived with their learnings — pruned, not wasted.

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: intent, reports, proposal, North Star.

Specs and tasks

Each candidate is turned into a spec by a pluggable spec tool, then decomposed into implementable tasks. Planning is where the strongest models earn their cost; the spec is the contract every task traces back to.

Model routing

Different stages warrant different strength. Route planning to a frontier-class model, implementation tasks to faster ones, review to a panel — configurable per stage, per project.

Approvals and autonomy

Human checkpoints are first-class objects in the pipeline, not settings buried in an admin page. Intent approval, promotion, review sign-off, merge — each can require a human's yes, and each can be dialed from fully supervised to fully autonomous as trust grows. You decide what ships.

Humans and agents, one model

Agents are not a feature bolted onto a human tool. Humans work through a fast, focused interface; agents work through a first-class CLI and public API. Both act on the same domain model — the same intents, specs, tasks, and gates — so coordination stops being a translation problem.

Review and improvement

Implemented work is reviewed — by humans, agents, or a panel of both. Review findings route backward: a fix loop reopens the task, a re-spec loop reopens the plan. In a tournament, review selects the winning candidate. After merge, post-merge analysis compares the scores that matter and the deltas land in the record — then the findings seed the next intent, and 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. Stella Loop takes the place of the issue tracker — it does not take the place of your stack.