supabase / cli / 32062783237
62%
develop: 62%

LAST BUILD BRANCH: gh-readonly-queue/develop/pr-6301-94158474812f7b491387a909f3168f8d3b20b2e3
DEFAULT BRANCH: develop
Ran
Jobs 1
Files 95
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 62.406%. Remained the same
32062783237

push

github

web-flow 
refactor(stack): simplify managed stack architecture (#6218)

## Summary

Replace the managed local-stack coordination design with a smaller
architecture centered on one atomic JSON document per stack,
deterministic loopback ownership, and one detached supervisor.

- derive stack identity from the workspace, checkout, development
context, canonical local-project key, and stack name, so multiple
Supabase projects inside one monorepo remain isolated
- keep automatic ports sticky per stack while respecting configured
exact ports and deterministic control endpoints
- support detached start, later-process reattachment, stop, deletion,
and recovery after interrupted lifecycle operations
- keep Docker and native execution behind the same Effect-native
`@supabase/stack` package
- report running configuration drift without rebinding live services

## Why

The previous implementation spread these guarantees across SQLite,
repository adapters, claims and publication protocols, transition state
machines, operation polling, and a large contract-fixture corpus. Those
layers duplicated ownership and recovery responsibilities and made
ordinary user journeys difficult to follow.

The simplified model gives each invariant one owner:

- the stack document owns durable identity, sticky ports, lifecycle,
launch metadata, and runtime metadata
- the deterministic loopback endpoint owns process exclusivity and
reattachment
- the manager owns identity resolution, port planning, persistence, and
repair
- the supervisor owns runtime resources from reservation through
shutdown

## Identity and monorepos

A stack key combines workspace ID, checkout ID, development-context ID,
canonical local-project key, and stack name.

The local-project key is the canonical project path relative to its Git
worktree, or `.` for an ordinary non-Git folder. It is local identity
only: it is not a remote project reference or a config `project_id`.

This keeps sibling Supabase projects in one reposit... (continued)

5571 of 8927 relevant lines covered (62.41%)

6.65 hits per line

Jobs
ID Job ID Ran Files Coverage
1 32062783237.1 95
62.41
 GitHub Action Run
Source Files on build 32062783237