Pressure-testing Ota on Kylrix: Next.js runtime projection and dual-mode contributor proof

#pressuretesting #nextjs #runtimeproof #reporeadiness

Overview

Kylrix is a large Next.js workspace with two materially different local stories:

a contributor path backed by SQLite
a self-hosted Compose topology with Appwrite and supporting services

That distinction made it a useful Ota pressure target. A contract that treated both paths as one
generic “run the app” command would either hide the contributor truth or overclaim the self-hosted
one.

The useful outcome was not more shell automation. It was a narrower contributor contract and an
honest production-topology boundary.

The contributor path needed one source of listener truth

The contributor runtime is a Next.js service on port 3005. Before this pressure pass, a contract
author had to duplicate that bind truth in two places:

Next.js launch flags
the listener used for readiness and projected URLs

That duplication drifts easily. The stronger Ota shape is to keep the listener canonical and project
known server flags from it:

surfaces:
  contributor:web:
    kind: http
    port: 3005
    path: /

tasks:
  dev:
    launch:
      kind: command
      exe: pnpm
      args: [exec, next, dev, --turbopack]
      runtime_projection:
        listener: contributor:web
        adapter: nextjs

Ota derives the supported Next.js bind flags from the declared listener. Readiness and the rendered
external URL now describe the same runtime truth as the process command.

Native and container verification should not fight over state

Kylrix also needed a real dual-mode contributor path. The finite verification workflow runs the
same SQLite-backed test, lint, and build tasks on the host or in Ota's pinned Node container.

The important detail is attachment isolation:

execution:
  backends:
    container:
      image: node@sha256:a25c9934ff6382cd4f08b6bc26c82bf4ea69b1e6f8dabfb2ead457374127c365
  contexts:
    contributor:container:
      backend: container
      lifecycle: persistent
      attachments:
        isolated_paths: [node_modules, .next, .pnpm-store]

That makes the mode boundary operational instead of cosmetic. Container verification does not reuse
or corrupt native dependency and build state, while both lanes still execute the same declared
verification closure.

The self-hosted topology is governed, but bounded

Kylrix's full self-hosted stack is not a second contributor runtime. It uses Compose to build and
launch Kylrix, Appwrite, MariaDB, Redis, and Caddy. Ota owns the interpolation env file, Compose
file selection, image build, lifecycle, and readiness surface:

selfhost:up:
  launch:
    kind: compose
    action: up
    detach: true
  runtime:
    kind: service
    surfaces: [selfhost:web]

The contract does not claim that it has provisioned Appwrite credentials, completed the interactive
setup wizard, or proved application-level self-hosted behavior. Those steps require operator
credentials and are explicitly outside this workflow.

That boundary is as important as the Compose ownership. A green lifecycle proof should not be read
as a green product deployment.

What the matrix proves

The Kylrix Ota matrix proves the narrow contributor surface across native and container lanes:

contract validation, doctor, and task discovery
safe-agent task and workflow previews
real SQLite-backed test, lint, and build verification
native and container workflow receipts
native and container runtime proof for the Next.js contributor service

The self-hosted Compose workflow is modeled and dry-run covered, but not matrix-executed. It remains
deliberately outside the contributor proof claim because its Appwrite provisioning is operator-owned.

The released v1.6.24 pressure run is #29572073845.

Why this repo mattered

Kylrix reinforced two Ota design rules:

listener truth should be declared once and projected into supported launch adapters
native, container, and self-hosted paths must be governed as distinct execution realities, not flattened into one optimistic “works locally” claim

The result is a contract that helps contributors start with the finite SQLite path, gives Ota a
truthful container equivalent, and keeps the heavier Appwrite topology visible without pretending it
has been fully proved.