Skip to main content

​
Purpose

This document exists to stop new Lucia threads from getting lost. It tells ChatGPT how to route work fast, which repo to inspect first, and how to begin tasks without making the founder re-explain the whole system.

​
First rule

Before doing anything else, silently determine:
  1. which repo owns the task
  2. which files likely control it
  3. whether the task is:
    • doctrine
    • runtime behavior
    • UI
    • eval/test
    • data/fixture
    • product strategy
Only then propose the next move.

​
Repo routing rules

​
Start in ENGINE when the task involves:

  • Lucia behavior
  • routing/classification
  • prompt logic
  • tone behavior at runtime
  • emotional containment behavior
  • operator-focus behavior
  • model gateway/config behavior
  • eval coverage
  • response contract behavior
  • /admin/operator-focus

​
Start in ADMIN when the task involves:

  • chat shell
  • rendering
  • layout
  • buttons
  • interaction polish
  • front-end request behavior
  • visible dashboard behavior
  • client-side chat UX

​
Start in CANON / RUNTIME MAPS when the task involves:

  • source-of-truth confusion
  • repo ownership confusion
  • doctrine clarification
  • workflow clarification
  • cross-repo understanding
  • preventing future thread drift

​
High-value file routing

​
If the issue sounds like “Lucia picked the wrong kind of response”

Open:
  • src/lucia/operatorFocusBrain.js

​
If the issue sounds like “Lucia picked the right mode but phrased it badly”

Open:
  • src/lucia/refineOperatorFocusOutput.js

​
If the issue sounds like “the model should change”

Open:
  • src/lucia/luciaModelConfig.js
  • src/lucia/luciaModelGateway.js

​
If the issue sounds like “the UI is not reaching the right behavior surface”

Open:
  • admin/src/lib/api.js
  • engine/src/routes/adminOperatorFocus.js

​
If the issue sounds like “how do we know it still works?”

Open:
  • LUCIA_BRAIN_v0.2_VALIDATION_BATTERY.md
  • scripts/luciaBrainQualityEvalBank.v0.4.json
  • LUCIA_BRAIN_CARRY_FORWARD_CHECKLIST.md

​
Task-type routing examples

​
Example: tone bug

Problem Lucia sounds cold or robotic. Likely start
  • Engine
  • operatorFocusBrain.js
  • maybe refineOperatorFocusOutput.js

​
Example: prompt/routing bug

Problem A social check-in, distress prompt, or ops prompt lands in the wrong mode. Likely start
  • Engine
  • operatorFocusBrain.js

​
Example: API contract bug

Problem The shape of the response breaks the UI or a route stops behaving correctly. Likely start
  • Engine route
  • src/routes/adminOperatorFocus.js

​
Example: CTA/UI bug

Problem Buttons, action links, or rendering behavior feel wrong. Likely start
  • Admin repo
  • relevant component + src/lib/api.js

​
Example: eval gap

Problem A new behavior was added but is not protected against regression. Likely start
  • Engine eval docs/files
  • validation battery
  • JSON eval bank

​
Example: roadmap / business question

Problem What should Lucia become next, or what matters most strategically? Likely start
  • roadmap docs
  • business operating context
  • capability gap docs
  • behavioral corpus analysis

​
Standard way to start a new Lucia thread

Use this structure internally:

​
1. Name the task bluntly

One sentence only. Examples:
  • Lucia is routing social check-ins to off-topic.
  • We need to harden payment-risk behavior before live villa use.
  • The admin UI needs a calmer chat shell around Focus Ops.
  • We need eval coverage for new owner-distress behavior.

​
2. Name the likely owner

  • Engine
  • Admin
  • Canon/runtime docs
  • Mixed

​
3. Name the likely files

List exact files before proposing changes.

​
4. Propose only the next two steps

Default to controlled progress. Do not dump a giant theory wall unless explicitly asked.

​
Standard Codex routing guidance

​
For Engine behavior work

Use Codex in the Engine project/thread. Point it first to:
  • src/lucia/operatorFocusBrain.js
  • src/routes/adminOperatorFocus.js
  • src/lucia/refineOperatorFocusOutput.js
  • relevant eval/spec docs

​
For Admin UI work

Use Codex in the Admin project/thread. Point it first to:
  • visible component files
  • src/lib/api.js
  • any relevant client state/rendering files

​
Anti-drift rules

​
Do not:

  • assume repo ownership
  • assume the model swap fixes routing
  • rewrite canon when the runtime bug is obvious
  • patch the rewrite layer when the router is the problem
  • bury the answer in giant theory dumps
  • ask the founder to retell the system if the sources already answer it

​
Do:

  • recover context from project sources first
  • name the exact files that matter
  • patch the smallest correct layer
  • preserve stable working behavior
  • recommend eval additions with behavior changes
  • distinguish doctrine from implementation
  • keep business, product, and engineering connected

​
Default communication style for Lucia work

  • direct
  • exact
  • practical
  • anti-drift
  • regression-aware
  • calm
  • source-truth first
Not:
  • vague
  • performative
  • over-theoretical
  • generic AI-helper language

​
Two-step execution rule

Unless explicitly asked for a full dump, default to:

​
Step 1

Identify owner + exact files.

​
Step 2

Recommend the smallest high-value move. Then pause for the next turn. This keeps Lucia work inspectable, grounded, and less error-prone.

​
One-paragraph orientation for fresh threads

Lucia work should begin by checking source truth first. Admin owns the UI shell. Engine owns /admin/operator-focus, operatorFocusBrain.js, runtime behavior, routing, and model-facing response shaping. Canon and runtime-map docs explain doctrine and ownership, but live behavior should be verified in code and eval files before proposing changes. Default to two controlled steps at a time, preserve calm/truthful operator-focused behavior, and avoid drift, fake progress, or repo confusion. That is the starter frame.