The system after Nyx

Build the graph. Keep one source of truth.

The new system turns a product goal into bounded work, lets compatible tasks move in parallel, protects shared resources, and accepts only what works in the integrated product.

Explore the graph Read the build goal Phase 1 gate proof Phase 2 gate proof Phase 3 backend proof

one state writer direct + graph lanes acceptance before success

one authority bounded workers

Phase 3 backend slice accepted149 deterministic · Phase 1 gate 5/5 · graph gate 4/4 · backend live 1/1

1state authority

2execution lanes

3initial worker cap

6recipe ceiling

Name it together

Pick the name before we bake it in.

These are pronounceable directions, not a fake final decision. Tap one to preview it across this page. The choice stays in this browser until you explicitly approve a name.

Removed after collision checks

Rivet

Gantry

Lattice

Mosaic

Relay

Orbit

Forge

Tandem

Trellis

Braid

Interactive graph lab

See what may run—and why.

Switch between a direct fix, a visual-foundation decision, and a long build. Select any node to inspect its dependencies, mode, and resource claims.

Tap a node · advance one deterministic event at a time

Waiting Ready Running Accepted Blocked

ACTIVE RESOURCE CLAIMS

Only running nodes hold live write or physical-resource leases.

No active leases

This is a simulator. It demonstrates the binding contracts but is not connected to a live system daemon yet.

Binding model split

Sol writes the packet. Luna ships the slice.

Sol plans every change and keeps splitting until one Luna xhigh worker can complete one meaningful outcome without inventing architecture or wandering into adjacent work.

gpt-5.6-sol · high

Plan + decompose

Interprets the goal, freezes decisions, builds the graph, and writes exact implementation packets.

No product-code writes
No scheduling or state ownership
Replans only affected nodes

Luna packet 800–2,000 structured words

gpt-5.6-luna · xhigh

Implement + return

Changes only the owned surface, runs offline worker checks, and returns unstaged work with hashed evidence. The trusted controller seals the commit.

One observable outcome
One primary write domain
Stop instead of widening scope

tests + fresh Sol review

Accept independently

Deterministic checks run first; a fresh read-only Sol context judges contract, code, visual, and integrated product fit.

LUNA FIT GATE

A task launches only when all six lights are green.

01One outcome

One sentence names the behavior that becomes true.

02One write domain

One feature, foundation, interface, or schema owner.

03Pinned inputs

Base commit, contract, foundation, and dependencies are fixed.

0420–60 minutes

One bounded attempt; uncertainty or larger work returns to Sol.

052–6 checks

Offline worker commands plus trusted host-only verification.

06Explicit non-goals

No adjacent cleanup, redesign, refactor, or scope expansion.

Descriptive without becoming huge

Structure beats a giant prompt.

Luna gets current behavior, desired behavior, pinned inputs, exact ownership, a required sequence, non-goals, checks, evidence, and stop codes. It does not receive the entire repo history.

Two independent outcomes → split Two write domains → split Unresolved decision → back to Sol Scope drift → stop, don't improvise

identity: LUNA-UI-017
outcome: caregiver card opens the real timeline
base: 91f2c6 · foundation: helios-v4
writes: feature:person-home
allowed: src/features/person-home/**
must:
  - preserve the approved card anatomy
  - route to /people/:id/timeline
  - expose loading and empty states
must_not:
  - change navigation or shared tokens
  - add a live-pulse control
accept:
  worker: focused behavior test
  trusted: 402px running-product capture
stop: contract_gap | needs_split | dependency_stale

Long-task operating horizon

Keep the destination. Reveal the next terrain.

A giant product is never flattened into one prompt. The complete outcome stays durable while only the next one or two integration milestones become a fully executable graph.

Unattended by contract

One request in.
A finished product out.

No mid-build taste votes, architecture questions, decomposition approvals, or visual checkpoints. Ordinary uncertainty is work for Sol to research and resolve—not a reason to wake the operator.

Research the unknown

Record a reversible assumption and continue.

Select the foundation

Fresh Sol review chooses from running code against the contract.

Build through proof

Luna implements; checks, acceptance, and integration continue automatically.

Deliver, then revise

Later feedback creates a new goal; it never blocks the first delivery.

Standing policy preauthorizes ordinary build and deploy actions. Missing external authority produces the safest useful fallback—not an idle approval queue.

OUTCOME HORIZON

The complete product

Users, non-goals, release boundary, and final proof survive for the entire build.

months

ARCHITECTURE HORIZON

Stable subsystem map

Interfaces, ownership, dependency direction, and security boundaries prevent local drift.

milestones

INTEGRATION HORIZON

The next 1–2 milestones

Only near work is fully graphed, resource-checked, and acceptance-ready.

days

EXECUTION HORIZON

One Luna packet

One outcome, one write domain, exact checks, and a 20–60 minute attempt.

minutes

My speed contract

Optimize accepted wall time—not agent activity.

Critical path first

Run the ready task that unlocks the most downstream work.

Interfaces early

Accept high-fan-out schemas and foundations before feature fan-out.

Warm the boring work

Reuse clean environments, dependencies, compiler output, and code maps.

Affected checks

Test the leaf now; pay the full-system cost only at named boundaries.

Compatible batches

One queue integrates disjoint results and runs their check union once.

Adaptive concurrency

Add workers only while ready domains, resources, and integration can absorb them.

Example product horizon

A browser becomes a chain of running products.

This is software the system could be asked to build—not its worker browser tool. Start with a real shell on a pinned WebKit or Chromium engine, or explicitly scope a new engine as a portfolio of subsystem programs.

01
Shell + navigationload · back · forward · reload · visible failure
02
Tabs + recoverywindows · sessions · forced restart · exact resume
03
User datahistory · bookmarks · downloads · permissions
04
Security + releaseprivacy · sandbox · updates · rollback · accessibility
05
Engine ownership, laternetwork · parser · JS · layout · paint · media

Separate tooling boundary

Workers initially share one brokered BrowserHarness session backed by one Playwright adapter. The browser above is the enormous product example, not that testing resource.

Remove from the fast path

whole-project detailed plans

full suites per leaf

review every trivial node

default candidate tournaments

repo-dump prompts

handoff-only agents

Small control plane

Modular capabilities. One boring authority.

Agents supply judgment and implementation. Deterministic code owns state, permissions, resources, acceptance, and integration.

ProjectController

The only execution-state writer. Reacts to events instead of racing multiple polling loops.

deterministic kernel

WorkGraph

Tracks dependencies, artifact versions, readiness, invalidation, and milestone epochs.

DAG + lineage

ResourceBroker

Grants compatible read, write, and physical-resource leases with fairness and expiry.

collision control

ResultAcceptor

Separates a worker process exiting from the integrated product actually being accepted.

truth boundary

IntegrationQueue

Promotes one compatible result at a time and reruns affected checks on the real branch.

ordered promotion

Direct lane

Preserves context and speed when decomposition would cost more than it saves.

ContractImplementVerifyMerge

Bug fixes and contained UI changes
One owner, one bounded result
Same acceptance and integration contracts

Graph lane

Earns its overhead when work is parallel, long-lived, resource-bound, or failure-prone.

Whole products and multi-day builds
Compatible work moves in parallel
Only affected dependents are invalidated

Anti-overengineering constitution

Every new mechanism must earn its weight.

The new system has explicit ceilings so a useful kernel cannot quietly regrow into a platform of competing schedulers, stages, supervisors, evidence generators, and retry paths.

Read the binding rules

State writers1per project

Retry paths1one bounded decision

Recipes≤6until evidence earns more

Design candidates1–3one by default

Kernel size3–6kexecutable LOC target

Merge queues1per project

Implementation file200–400logical LOC target · review above 500

No graph database

SQLite nodes, edges, events, leases, and versions are enough until measured scale proves otherwise.

No arbitrary workflow DSL

Six tested recipes beat an agent inventing a new lifecycle for every request.

No supervisor stack

One controller, one slow safety sweep, and explicit provider-process cleanup.

No unused evidence

Every artifact names a consumer; unconsumed output is waste, not progress.

Deletion accompanies addition

Every mechanism proposal identifies the failure it prevents and what it replaces or removes.

Product proof wins

Integrated behavioral and visual evidence outranks process receipts and screenshot quantity.

Source shape is a navigation budget

Files average 200–400 logical lines within a module. Crossing 500 triggers a cohesion review—not blind rejection or tiny-file theater.

Shared product-design standard

Wobbleby confidence. Product-owned identity.

Reuse the craft: neutral sans typography, purposeful radii, disciplined color, real interactions, flat original graphics, and running-code review. Never copy Wobbleby's palette, mascot, content, or layout.

PRODUCT DESIGN CONTRACT

Rounded with purpose, never rounded by habit.

Shape, space, color, and depth communicate hierarchy before decoration.

Foundation v7

Content card24pxoutline by default

Input18px

Chip · 12px

Typography

Inter-style neutral sans for UI
Inter Tight only for display
No decorative serif by default
Paragraphs stay regular weight

Canvas + color

True white or deliberate dark fields
One dominant hue per screen
No beige or pastel full canvas
Gray provides hierarchy, not brand

Shape + depth

8 / 12 / 18 / 24 / 32 radius ladder
Beautiful 1px outlines by default
Shadows only for floating surfaces
No pill or card repeated everywhere

Controls

44px minimum target
One primary action per viewport
Every enabled control really works
No decorative live-pulse button

Graphics + motion

Original flat 2D or code-native art
No glossy AI spheres or fake glass
Motion settles in about 160–320ms
Reduced motion always supported

Acceptance

Judge real running screens
Use representative data and flows
Review the combined application
Screenshot counts never prove beauty

Never by default

cream canvas

pastel soup

fancy serif UI

generic gradients

card-stack sameness

decorative pulse

Build order

Prove one loop before expanding the system.

Each phase ends in observable behavior and a hard gate—not another architecture layer.

ACCEPTED · FOUNDATION

Authority and contracts are pinned

Clean source, legacy evidence, autonomy policy, model routes, packets, results, and exact event fixture are accepted.

ACCEPTED · DIRECT GOLDEN LOOP · 5/5 CANARIES

Direct work survives reality

Single-file replay, exact multi-file and new-file ownership, evidence-guided clean retry, and controller-reopen worker recovery all pass with real Sol and Luna.

ACCEPTED · GRAPH + RESOURCES · GATE 4/4

Compatible work runs safely

Persisted DAG lineage, fair recoverable leases, exact ordered integration, two-project overlap, writer serialization, and real process-family isolation all pass.

NOW · BACKEND LIVE 1/1 ACCEPTED · UI NEXT

Finish the product-module gate

The real backend graph slice passes. Next: UI foundation and UI change with running-product behavior and independent visual acceptance.

LONG BUILD

Resume a real application milestone

Dependency waves, incremental integration, graph compaction, bounded replanning, and system proof.

AUTHORITY SWITCH

Beat the legacy system honestly

Matched canaries, cost and recovery comparison, release isolation, then read-only archive.

HERMES · LATER

Add conversation after stable control

Versioned read-only explanation first, then signed policy-checked commands—never a second orchestrator.

Future interface · deliberately later

Talk to Hermes. Let the builder do the work.

Hermes becomes the conversational operator after the builder has a stable command and query API. It explains and issues already-authorized requests under standing policy. It never becomes a second state owner or coding runtime.

YouHermesBuilderWorkers

Read-only project explanation ships first.
Mutating commands are signed and policy checked.
Hermes never edits, accepts, locks, or merges code.

What is holding up the caregiver dashboard?

Visual verification is waiting on Home UI commit 91f2. The API work is already accepted, and no other task is blocked.

Ask about the project…

The operating thesis

Ambitious outcomes.
Smaller mechanisms.

The new system keeps the part of Nyx that behaved like dependable infrastructure and replaces the part that confused activity with a finished product.

Open the complete goal Back to top