CONTEXT / WHAT THE SYSTEM KNOWS
No blank-slate sessions.
Project instructions, decisions, recent state, and peer activity establish the starting point. The research bay carries verified findings across projects.
Recall→Verify→Reuse
AN OPERATING SYSTEM FOR BUILDING PRODUCTS
How a prompt
becomes a product.
A human sets the direction.
Agents turn it into working software.
Around them: a system that checks,
remembers, and keeps improving.
ONE IDEA. MANY CHECKS. A CONTINUOUS LOOP.See it in action
01 / THE BIG PICTURE
Two starting points.
The same system behind them.
Choose an example, then open any step.
The prompts below are illustrative.
CHOOSE YOUR FRONT DOOR
>_ Codex⇄✳ Claude Code
Same repositories, memory, skills, rules, and tooling.
Pick up the work in either harness; model and review routing follow that harness.
Every release informs the next run.User feedback, production signals, and verified lessons return to the start.
Forward progressFeedback → revise → recheckSteps can overlap; checks still have to pass.
02 / AROUND EVERY STEP
The invisible part
does a lot of the work.
The agent gets a working memory,
a shelf of playbooks, and checks
around the tools it uses.
SKILLS / HOW THE WORK GETS DONE
A library of playbooks.
Loaded when they fit.
A skill carries a repeatable method, scripts, templates, and evidence requirements. The agent selects the relevant ones for the task.
HOOKS / CHECKPOINTS AROUND TOOL USE
The harness has a lifecycle.
Some hooks block an action. Others inject context, record activity, or advise. Workflow requirements still need real evidence.
ADVISORY, NOT APPROVAL
Jev adds skill hints and checks around changes, commits, research, and replies. It can surface concerns; it does not replace tests, fresh review, or human authority.
03 / THE DESIGN FEEDBACK LOOP
Good design gets
challenged before it ships.
For explicit brand and UX work.
Routine fixes keep the existing design.
REAL PRODUCT CONTEXT
Brief + references
Flows + constraints
Rendered evidence
EQUAL PEERS · EXCHANGE, DON'T RUBBER-STAMP
SSolCodex
propose · challenge⇄revise · inspect
OOpusClaude
Agree on the same version + inspect the rendered result
F
Fable decides.
Accept, name changes,
or redirect the design.
Justin keeps the product direction. Concepts, feature boards, design systems, screenshots, and real interactions give the discussion something concrete to judge.
Model roles & the availability fallback +
Normal design seats: Sol 6.1 and Opus 5.5, followed by Fable 5.1; each at xhigh or higher. When Claude usage is unavailable, the authorized Codex-only route retains rendered inspection, independent Codex review, and deterministic checks. This infographic used that fallback; no Claude or Fable review is claimed.
04 / ONE FEATURE, COORDINATED ACROSS REPOS
You describe the feature.
The system splits the work.
The request stays at product level.
The implementation follows the
responsibilities it actually touches.
THE HIGH-LEVEL REQUEST
“Let members move a booking—on the web and in the mobile app.”
ILLUSTRATIVE EXAMPLEWorkspace repository
Shared context · cross-repo plan · API contract · acceptance criteria
Coordinates independent Git repositories. These are not Git submodules.API
Move operation.
Permissions, conflicts,
consistent allowance.
Web
Move-booking flow.
Validation, availability,
confirmation states.
iOS
Native interaction.
Shared API contract,
device verification.
Android
Companion behavior.
Same feature contract,
native implementation.
Landing
No change needed
unless this feature
changes public claims.
Integrate the feature, not just the branches. Named owners and scoped tasks keep parallel agents coordinated. Contract dependencies land in order; the complete journey is verified across the affected surfaces.
Reviewed PRs are the merge point for product repos.
Each repo carries its own diff, checks, review, and release. A shared workspace does not turn them into one giant commit. Ops has its separate reviewed-and-gated direct-merge policy.
MOBILE IS A FULL RELEASE LIFECYCLE
From a native build
to a real install.
App Store ConnectGoogle Play Console
Sign + test→Beta delivery→Submit→Review→Publish + verify
The system manages app records, signing, screenshots, listings, privacy declarations, and populated reviewer access. It follows review feedback through fixes and resubmission, then proves the exact build is installable.
↶ Store feedback returns to the affected repo and its checks.
THE WORK EXTENDS BEYOND THE EDITOR
Cloud consoles
are part of the job.
DNS + hosting + domainsIdentity + OAuth + app capabilitiesError reporting + analytics + monitorsSigning + push + store configuration
Agents use supported APIs and CLIs, then authenticated browser consoles where needed. They verify the exact account and app, use scoped credentials, and read back the resulting state. Account-holder decisions and human action gates remain with Justin.
05 / FROM WORKING LOCALLY TO RUNNING FOR REAL
Three environments.
Clear boundaries.
The Kommonz pattern: isolated work,
a hosted dev environment, and
a dedicated production VM.
01
Local / task
BUILDfeature branch
code → run → testEach change has a branch and worktree. Disposable databases and preview services keep tests scoped to the task.
- Fast iteration + regression tests
- Preview evidence before release
- No real customer data needed
tested change→
02
Hosted dev
INTEGRATEWEB + API
DEV DATA + JOBS
TEST INTEGRATIONS
A durable development deployment runs separately from coding checkouts, with its own environment and data.
- Full journeys + integration checks
- Shared dev is distinct from a preview
- Build + lint + review before promotion
reviewed release→
03
Production
SERVEWEB + API + WORKER
DATABASE + STORAGE
MONITORS + BACKUPS
Kommonz runs in an isolated production VM, with its own database, services, tunnel, and deployment runner.
- Release checkout + persistent data
- Health, smoke checks + rollback
- Live build and behavior verified
Kommonz’s production VPS is a dedicated virtual machine on the existing physical host. Local work and hosted dev stay outside that production boundary.
THE REQUEST PATH
Cloudflare is the front door.
The product has its own home.
A visitorBrowser / native app
CloudflareDNS · TLS · edge protection
Static landing → edge assets
Cloudflare Workers + static assets
App + API → tunnel → production VM
Web · backend · jobs · auth · storage
Postgres stays private
App backends live on the server.Production data lives outside release checkouts.Mobile clients use the same API contract.
The production-readiness checklist +
Application
Real end-to-end flows, permission boundaries, validation, loading and error states, persistent data, regression coverage.
Delivery
Repeatable builds, scoped environment configuration, CI checks, fresh review, a release marker, health checks and a rollback path.
Data & operations
Private database access, production-change approval, backups with restore verification, scheduled jobs tracked in the owning repo, logs and alerts.
Proof
A real user journey on the deployed build, working monitors, error and analytics evidence or an explicit closed telemetry gate, and task-resource cleanup.
06 / PRODUCTION IS THE BEGINNING OF THE NEXT LOOP
If it runs,
we need to see it.
Observability is built in before
the first feature. A green deploy
alone is not the finish line.
What happened?
Structured boundary events carry useful context and request IDs, without secrets or personal payloads.
pino → journald → Alloy → Loki
What broke?
Sentry captures failures where a decision is made, with a fingerprint, tags, and enough context to investigate.
Decision point → Sentry → triage
Did it help?
PostHog records meaningful user actions and product journeys. Production analytics and replay are gated away from test builds.
User action → PostHog → insight
Is it still working?
Service health, deeper dependency probes, job freshness, dashboards, and alerts reveal what needs attention.
Health + freshness → Grafana alerts
The signals connect. Request IDs, session IDs, and error-event IDs link a failure to the logs and user journey around it.
SIGNALAlert or user feedback
MISSION CONTROLDeduplicate + triage
SCOPED WORKDiagnose + repair
PROOFRetest + verify recovery
Bounded automation. Eligible repairs use repository locks, budgets, limited retries, and escalation when they cannot close the issue.
A closed loop. Recovery evidence resolves the condition; the cause and useful learning feed the next change.
06 / THE HUMAN AND THE FINISH LINE
Autonomy with
clear decision points.
Justin sets intent and steers the work.
The system carries authorized work
through to a verified result.
Stays with the human
Real production-data changesMoney movementOutbound messages to peopleRestricted-product production promotion
Done means the thing you open actually works.
The live artifact matches the tested build. The backlog is reconciled, disposable task resources are cleaned up, and verified lessons are ready for the next prompt.