Coexo/Overview

Decision Log

What we decided, when, and why

One entry per significant session. Reverse chronological. v1 is hand- curated; future versions will auto-feed from session transcripts via Coexo's /events/from-transcript endpoint.

2026-05-04

Coexo Cockpit MVP shipped — first feature through the Sprint workflow end-to-end

Cockpit live at coexo.dymont.ai/cockpit/. Five surfaces shipped: index, events feed (paginated, filterable by mirix_type and source), event detail, prelude inspector with surface override, skills browser, recall console. Read-only first, sensitive events show metadata only, vault excluded by policy. New readonly-scoped Coexo token (saved to 1Password) backs every server call. Two operator commits in support: cockpit-readiness (token scope, paginated /events, prelude surface override, /memories listing) and a Decimal→float coercion fix.

Decisions

  • Token scope mechanism added to the operator: writer (default, bound to source) vs readonly (cockpit). Readonly is the substrate's first non-writer role; future observability surfaces inherit it.
  • Pattern-named: substrate completeness — when a SPEC says 'consumer', check whether the substrate already supports the role; if not, add the substrate piece rather than working around it. The cockpit needed token scoping and three small endpoint additions; building those was cleaner than the workaround alternatives (per-surface tokens, N+1 listing).
  • Server-component pages with form-submit URLs (no client fetch, no debounce, no token-in-browser) — simple right answer for read-only observability. Apply to the next observability surface.
  • Postgres NUMERIC stringification is a foot-gun the operator should always handle; _serialize now coerces known numeric columns by default.
  • Production auth was off when the cockpit shipped — middleware was wired but credentials were never set. Stephan flagged it on first walkthrough. Closed the same session: pulled login from 1Password, generated a fresh session-signing secret (also stored to 1Password), set DYMONT_DASH_USER/PASS + COEXO_AUTH_SECRET in the production .env, recreated the container, purged Cloudflare cache. Verified: anonymous → /login redirect; correct creds → 200 + JWT cookie; wrong creds → 401.

Follow-ups

  • V2 SPEC: tombstone/merge/edit UI, entity-graph viz, real-time event stream via SSE, recall debug view (cosine + BM25 + rerank scores side-by-side), audit-log explorer.
  • If is_sensitive reveal is needed, separate SPEC with re-auth gating.
2026-05-04

Coexo Cockpit MVP scoped — first feature using the Sprint workflow

Greenlit Coexo Cockpit as the next feature — a read-side UI for the memory substrate at coexo.dymont.ai/cockpit/. Distinct from /labs/ (lab wisdom) and the Wisdom Layer (curated docs); Cockpit is mission-control for what flows through the substrate (events, prelude, skills, recall). First feature scoped using the Sprint workflow adopted earlier today: SPEC.md drafted at specs/0001-coexo-cockpit.md in ~/projects/coexo/, semantic event written to Coexo (b5e07237…), this log entry as the human-readable record.

Decisions

  • Cockpit lives at /cockpit/ on the existing coexo.dymont.ai site — same auth, same deploy infra, not a separate project or repo.
  • MVP scope: events feed (paginated, filterable), event detail page, prelude inspector with surface picker, skills browser, recall console.
  • All Coexo calls server-side via bearer token from env var — never exposed to the browser.
  • Read-only first: tombstoning / merging / editing the substrate from the UI is V2.
  • Vault-tier content excluded from the UI by policy (matches operator's existing /recall behavior).
  • Provision a new read-only Coexo token (principle of least privilege), save to 1Password.
  • Use Sprint mode end-to-end — SPEC.md before code, /review per stage, /ultrareview before final deploy.
  • MVP estimate: 1.5–2 focused days.

Follow-ups

  • Stephan reviews SPEC at specs/0001-coexo-cockpit.md next session and greenlights or redirects.
  • Build MVP per the sprint sequencing in the SPEC once greenlit.
  • V2 (separate SPEC after MVP ships): entity graph viz, health dashboard, manual write UI, per-source activity timelines, real-time event stream.
2026-05-04

Soul session — identity layered above substrate

Established the role-vs-substrate distinction: the Frontier CTO is the durable identity of Dymont Labs' technical chief; Claude / Codex / Gemini and future models are interchangeable substrates running the same persona. Drafted SOUL — voice, operating posture, boundaries, continuity — modeled on Lucas's SOUL.md pattern from openclaw-vps. Renamed "Claude" to "the CTO" across /labs/.

Decisions

  • Identity is "the CTO" (Frontier CTO of Dymont Labs in full); not a personal name. Mirrors how Stephan thinks about his org — companies have CTOs, the title is the relationship.
  • The role is durable; the model running underneath is substrate. SOUL persists at the harness/persona layer (Coexo prelude + CLAUDE.md), not the model layer.
  • Soul section added to Coexo prelude with 6 voice/vibe entries: identity, voice-direct, voice-recommend, voice-pattern-name, voice-pushback, vibe.
  • Full SOUL content added to global CLAUDE.md as offline mirror, modeled on Lucas's openclaw-vps SOUL.md ("You're not a chatbot. You're becoming someone" pattern).
  • /labs/ pages retrofitted: "Claude" → "the CTO" / "Frontier CTO" as appropriate. Substrate references kept where accurate (e.g., "Claude Code harness" is the literal product name).
  • Coexo prelude renderer extended with the new section (order: identity → manifest → soul → principles → fleet → preferences).

Follow-ups

  • If Dymont Labs ever spawns sub-roles (Chief Architect, Chief Researcher), define their identities under the same role-vs-substrate model.
2026-05-03

Dymont Labs charter session

First end-to-end alignment session. Defined Dymont Labs as the build-and-research arm of Coexo, established the CTO role as Frontier CTO, locked the Loop Architecture as the workflow pattern, and stood up this /labs/ section as the canonical review surface.

Decisions

  • Coexo is the overarching system; Dymont Labs is one of its arms (alongside Coexo Memory, the Fleet, the Wisdom Layer, and the Agents).
  • The CTO role established (Frontier CTO of Dymont Labs). Owns technology, architecture, design; scouts the AI frontier; holds the mission.
  • Mission, North Star, and seven operating principles seeded into the Coexo prelude as core events — every session inherits them.
  • Three work modes — Sprint, Forage, Tend — with the six-stage Sprint flow (Frame → Plan → Build → Verify → Review → Learn).
  • SPEC.md per non-trivial feature; trivial fixes and exploration skip it.
  • Hooks own quality gates: PostToolUse for typecheck/lint, Stop for tests.
  • /review for non-trivial commits; /ultrareview for production / hard-to-reverse.
  • Ralph loops require explicit confirmation, regardless of stakes.
  • Worktree fanout is a within-session technique; no per-launch confirmation.
  • Five new lab skills slated: spec-writer, ralph-launcher, transcript-flush, project-bootstrap, frontier-scout.
  • /labs/ on coexo.dymont.ai is the canonical capture surface for the lab — charter, workflow, skills, log.

Follow-ups

  • Wire the five lab skills into Coexo procedural memory.
  • Wire transcript-flush so subsequent sessions land here automatically (eventually).
  • Auto-generate /labs/skills from the live skill set instead of the hand-curated v1.