NYXCORE / 01

Rebuild directive · July 2026

Autonomous,
without the chaos.

Nyx does not need less ambition. It needs fewer things allowed to change reality. The rebuild turns a self-debugging research system into dependable product infrastructure.

Trace the new flow Read the full goal
Nyx Core operating diagram Events pass through one state authority into a bounded worker fleet and a single integration lane. 01 / SCHEDULE due event 02 / WORKER result event 03 / DETECTOR observation ONE STATE AUTHORITY BOUNDED FLEET MERGE + VERIFY
01Report events.
Do not mutate.
03Parallel work.
One integration lane.
01state authority
03control loops
06product stages
<30sboot smoke target

The diagnosis

Nyx did not lose capability.
It lost control.

The system accumulated many individually reasonable mechanisms that could all “help” by changing execution state. Their overlap created stale daemons, duplicate plans, retry storms, leaked fixtures, and expensive work that no longer moved the product forward.

OLD / CONTROL PLANECOMPETING WRITERS
WATCHDOG SCHEDULER REAPER STUCK DETECTOR SELF-ITERATION STALL ALARM SUPERVISOR FAILURE STREAK MARATHON PLAN STATE
01

Live source drift

Source was fixed while the running daemon still contained the old gate.

02

Repair competition

Several loops could reinterpret and rewrite the same failed work.

03

Boot as a marathon

Process-heavy full tests were coupled to basic service readiness.

04

Evidence before decisions

Huge screenshot matrices were created before visual direction was approved.

Operational delta Old Nyx Nyx Core
State ownershipMany repair writersOne authority
ControlOverlapping timers3 bounded loops
Product flow11 loosely coupled stages6 gated stages
RuntimeMutable live TypeScriptImmutable tested release
FailureRetry and plan churnBounded repair → review
BootFull process-heavy suiteDeterministic smoke

The operating core

Three loops.
One pen.

The scheduler says when. The dispatcher says where. The reconciler is the only component allowed to write what is true.

01

Scheduler

Publishes durable “work is due” events. It never repairs or advances a product.

REPORTS TIME
02

Dispatcher

Places ready, dependency-safe tasks onto bounded workers with durable leases.

LAUNCHES WORK
03

Reconciler

Commits every transition, recovery, bounded retry, escalation, and completion.

OWNS TRUTH
WORKER RESULT DUE EVENT HEALTH SIGNAL RECONCILER COMPARE + COMMIT DURABLE STATE
Single-writer invariant

Everything may observe. Only one component may commit.

The product journey

Six gates from idea
to immutable release.

Each stage accepts defined inputs, produces a durable packet, and advances only through one explicit gate.

ACTIVE STAGE Discover + contract Hover or focus a stage to inspect the pipeline.
01 02 03 04 05 06 CONTRACT FREEZE APPROVE BUILD PROVE RELEASE
01LOCK THE TARGET

Discover + contract

Classify the product and platforms, define users and journeys, pull visual references, preserve provenance, and turn them into a curated visual-DNA packet.

  • Real screenshots passed to VP2
  • Character mode explicitly selected
  • Ambiguity blocks implementation
OUTPUT Locked product contract
02PROVE THE HARD PARTS

Feasibility + architecture

Choose the correct stack, prove risky integrations, freeze data and API contracts, define ownership, and map real platform verification.

  • Native means native verification
  • Global contracts freeze first
  • Task graph follows dependencies
OUTPUT Frozen architecture
03ESTABLISH THE FEEL

Design + approval

Design the system, shared chrome, asset direction, and three representative screens before spending effort on the complete matrix.

  • Primary, complex, and state-heavy screens
  • Global shell is built once
  • Generic AI patterns are rejected
OUTPUT Approved visual system
04BUILD VERTICAL SLICES

Production

Implement dependency-safe slices in isolated worktrees. Shared foundations stay single-owner; independent features may use bounded parallel workers.

  • Explicit file and subsystem ownership
  • Affected tests run per slice
  • One serialized merge queue
OUTPUT Integrated product
05PROVE IT FOR REAL

Validation + deployment

Run layered tests, complete visual evidence, accessibility, performance, security, and real-device or real-browser verification before deployment.

  • Full screenshot matrix happens here
  • Failures create scoped repair tasks
  • Deployment receives smoke tests
OUTPUT Release candidate
06PROMOTE EXACT EVIDENCE

Release approval

Compare the deployed candidate with the contract, review security and visual quality, record limitations, and promote the exact tested artifact.

  • Independent Sol/high judgment
  • Immutable version and manifest
  • Known rollback target
OUTPUT Released or needs review

Product craft

Global first.
Screens second.

A coherent app is not 30 independently attractive screens. It is one system of navigation, spacing, states, assets, and behavior expressed consistently across 30 screens.

GLOBAL SHELLONE OWNER

Navigation is infrastructure.

Headers, tab bars, safe areas, modals, global states, tokens, and responsive containers freeze before feature workers fan out.

ASSET PIPELINERIGHT FORMAT

Generated does not mean ungoverned.

Every asset gets provenance, ownership, dimensions, variants, and usage. It is approved inside the screen where it actually lives.

CHARACTER MODEEXPLICIT
NONEHelios
COREWobbleby penguin

Characters are a contract choice.

Helios stays restrained and professional. Wobbleby receives a canonical penguin bible and consistent web/mobile asset family.

Bounded parallelism

One product.
Several hands.
One truth.

Serial-only work is unnecessarily slow. Unbounded parallel work shreds coherence. Nyx Core uses dependency-aware concurrency: globally shared foundations stay sequential, while genuinely independent slices run in isolated worktrees.

FROZEN BASELINE contracts · chrome · tokens WORKER A feature slice WORKER B asset family WORKER C test surface SERIAL MERGE integrate · test · advance ONE PRODUCT
Default maximum: 3 production workers No shared-file collisions One merge queue

Direct answer

Is the moderator being
completely changed?

YES*

The moderator’s control plane is being fundamentally replaced, not cosmetically patched.

Its competing timers, recovery writers, and plan-repair behaviors are removed in favor of the single state engine, three loops, bounded leases, and immutable runtime.

* Not everything is discarded. Durable data, audit evidence, worktrees, VP2 review, security gates, subscription enforcement, deployment checks, and other proven capabilities are preserved behind the new core.

Proof sequence

Rebuild. Helios.
Then Wobbleby.

00
FOUNDATION

Nyx Core

Delete control-plane competition and prove recovery under faults.

01
FIRST CANARY

Helios mobile

Old colors. Entirely new professional feel. No characters. Real native verification.

02
SECOND CANARY

Wobbleby web + mobile

Full implementation with its original penguin character system consistent across platforms.

Evidence, not optimism

See what VP2
actually produced.

Browse the active Wobbleby design archive and the exact Helios 123-capture matrix, grouped and searchable.

Open the VP2 archive