Home / Ops / More in this area
Updated Jun 18, 2026 · Affirmology_ClaudeCode_BuildBrief_2026-06-18_v1.md
This is the work order for today's Claude Code session. Jeff approved it and is stepping away to the demo/investor videos. Sol is NOT on the Studio until later tonight, so the Studio can be in flux during the day. Build Studio first, then Atlas v1.
READ FIRST: Affirmology_PROJECT_STATE.md (source of truth), Affirmology_StudioChangeList_v1.md (the queue, top block is today's items), Affirmology_Atlas_Overview_v1.md sections 10-14 (Atlas decisions), and Affirmology_Persephone_GatePrompt_v1.md (the new gate). Honor CLAUDE.md.
pytest green after engine changes; node --check on JS; read the actual generated output before claiming it matches.natal_sacred (empty directive). Treat it as the demo candidate baseline; see item S6.Ordered by value-for-churning-audios and risk. Do them top down.
Problem: a Sol render used WRONG name-based numerology because it derived numbers from a partial/assumed name. Life Path (from birth DATE) is always fine. Name-based numbers (Expression/Destiny, Soul Urge, Personality) must only be used when a confirmed FULL name is on record.
- Engine (affirmology-agent/src/affirmology/chart/numerology.py): add a name_confirmed: bool to the input/chart payload. When false, compute Life Path and other date-only numbers normally, but DO NOT compute or emit name-based numbers (return them as null/absent, not guessed).
- Generator (script_generator.py) + reports + build report: when name-based numbers are absent, never reference them. No "your Expression number is X" anywhere unless confirmed.
- Studio: the people library and the composer must capture and pass the confirmed full name. If a person's full name is not confirmed, the composer prompts explicitly: "For numerology, what is your full birth name?" (state what is needed: full name as on the birth certificate, or first + last). Never infer "Jeffery" from "Jeff" or "Soledad" from "Sol".
- Seed data: mark the four known charts' names confirmed where we actually have the legal full name (Jeff = Jeffrey Alan Parker; Sol = Soledad Gabriela Ballard; confirm Colin's and Josh's full legal names before marking them confirmed).
- ACCEPTANCE: a render for a person without a confirmed full name contains zero name-based numerology in script, report, and blueprint; a confirmed person renders name-based numbers correctly. Add a pytest fixture for both. Re-check Sol specifically.
Problem: Sol was confused composing because each structure does not explain itself. EVERY audio type, every preset and the custom one, needs a ROBUST overview shown BEFORE composing. Plain prose is fine; it does NOT need to be in an agent voice (that belongs to the composer conversation, see S2b). Just a strong, clear overview.
- Data (api/structures.py): add fields to Structure: overview (a robust paragraph: what this audio is meant to do, its scope, the parameters it already works with, why it is useful), and optionally scope / why_useful if cleaner as separate fields. Fill a robust overview for ALL 14 structures AND the custom one (custom's overview explains that you write your own directive and what a good directive includes).
- Front-end (web/): render the overview panel at the top of the compose screen when a structure is selected, plus the "these are guidelines, shape your version freely" line.
- ACCEPTANCE: selecting any structure, including Custom, shows a clear robust overview before composing; the text is accurate to the directive.
This is where the agent voices live, NOT the overview. In the conversational composer, the assistant's messages are attributed to the actual agent doing that step (Sophia synthesizing, Persephone on the transformational arc, Chiron on techniques, Orpheus drafting, Apollo conducting), each with its name shown. One or more agents can be the one in communication. Tasteful and legible; makes the oracle council real and fun. (Already in Affirmology_StudioChangeList_v1.md Priority 1.5 and the v3 mockup composer.) Build this on the composer chat, separate from the S2 overview field.
- ACCEPTANCE: composer messages are attributed to named agents; the right agent speaks for the right step.
Problem: length is a 3/6/9 toggle; some audios (long journeys, full readings) need to be 45+ minutes.
- Replace the 3-tier control with a wide length choice: a slider or numeric input, roughly 3 to 60 minutes, defaulting to the structure's target_minutes (now an editable suggestion, the agent suggests, the user overrides).
- Engine: ensure the script generator honors a requested length well beyond the demo's ~6 min (word-count target scales with minutes). Watch the word cap that overran before.
- At long lengths: confirm ElevenLabs render time is acceptable and the music bed covers the full length (see S4). Long renders may need chunked synthesis; keep QC on the voice-only track.
- ACCEPTANCE: a 30-40 min script generates with a sensible word count; a rendered long audio has music for its full length and passes QC.
Problem: Heavenly Circuit is hard-wired onto everything; Jeff is adding more beds soon and wants them selectable by pace/use-case. - Add a bed selector to compose. v1 wires only what exists: None (dry voice) and Heavenly Circuit. Stop defaulting Heavenly onto everything; it is one choice. - Define the pace/use-case CATEGORIES now so new beds drop in without rework: Stillness/Delta (before-sleep, very slow), Journey/Theta (transformational, regression, womb-return), Movement (walk/gym, faster). Structure the bed registry as {id, name, category, bpm/pace, file} so Jeff adds beds by dropping files + a registry row. Leave the new categories defined but empty until he uploads. - Fix music COVERAGE for the chosen bed: loop/extend to the full audio length with a fade tail (this was a live bug at 7:32 when Heavenly ran out). - Future hooks (do not build now, just leave room): binaural-beat / sacred-tone / EFT-tap overlays layered on the bed. - ACCEPTANCE: compose lets you pick None or Heavenly; the selector lists the three empty pace categories ready for beds; rendered audio's bed spans the full length.
Add the new council member per Affirmology_Persephone_GatePrompt_v1.md. ENFORCED Apollo gate, not optional. Distinct from Chiron (Chiron = techniques; Persephone = the transformational arc, sized to audio type with nuance and context).
- First land the prompt in the council path (agents/council.py + Apollo's gate loop), additive, Studio-only, demo untouched (the --council path already gates this).
- Her one-line verdict prints in the build report next to Chiron's technique plan.
- Add an optional transformation_depth hint to structures.py so daily audios pass on a light arc and deep/journey/breakthrough structures require the full one.
- ACCEPTANCE: a Studio script runs through Persephone; build report shows her signed arc line; a deliberately flat-but-pretty draft gets a REVISE; the locked demo is unaffected (pytest green).
The natal_sacred structure IS our demo. Label it "(demo)" in the Studio UI. We must be able to create additional demo CANDIDATES; when one is ready, Jeff says so and it becomes the new locked demo. Until then the live demo stays locked and untouched.
- UI: show "(demo)" on the natal structure; allow saving a structure/version as a "demo candidate" tag (no effect on the live demo).
- ACCEPTANCE: natal shows "(demo)"; a candidate can be flagged without touching the production demo.
Many audios move too fast. Give the Studio a slower, more-spacious delivery option so recognitions land. - Try: SSML breaks / inline pause tags, slower speed within the QC-safe range, and moving Studio renders off Turbo to a slower ElevenLabs model for long/slow audios. This ties into the Fish Audio / ElevenLabs PVC evaluation already in PROJECT_STATE 17c; A/B them on one real script. - Keep the locked demo's speed-1.0 Turbo setting as is; this is a Studio capability only. - ACCEPTANCE: a before-bed or journey render is audibly slower with real pauses, still passes QC, demo untouched.
Reinforce the iterative composer (P0.2 done): keep ALL notes and the full version history; make it a true ongoing conversation; let someone keep changing or marking versions they like even AFTER an audio is rendered. Nothing is a dead end. - ACCEPTANCE: after rendering, the user can still edit notes, regenerate a new version, and mark a favorite; history persists across reload.
The Jeff+Colin, Jeff+Sol, Jeff+Colin+Sol work should be doable inside the Studio, not just via the engine. Wire chart/relationship.py into the composer as a multi-person path (Model A single-narrator "we" for now, per PROJECT_STATE 16). This is larger; if time runs short today, scaffold the UI + endpoint and finish after Atlas.
- ACCEPTANCE: a two-person synergy compose runs end to end in the Studio.
Our build reports must clearly show what information was obtained/used and what was left out and why (Sophia's synthesis, Chiron's techniques + "left out" note, Persephone's arc, the corpus sources used). These are BEHIND-THE-SCENES reports for us to tweak/fix, distinct from eventual client-facing reports. Make sure the build report surfaces the used/left-out detail prominently. - ACCEPTANCE: a build report names the systems/sources used and what was deliberately omitted and why.
Per Affirmology_Atlas_Overview_v1.md sections 7-14. Atlas is the same cloud Studio surfaced as an installable app with a Hermes-first, two-mode UI. The cloud move is done (Render + R2, PROJECT_STATE 19), so Atlas is unblocked.
Manifest + service worker + icon on the cloud Studio web app. Installs to iPhone/Android home screen and Mac dock, one Cloudflare Access login. Mobile-polished layout.
Hermes chat mode and full Studio mode, with an always-present corner toggle (upper-left or a corner) to flip between them. Default landing = REMEMBER LAST MODE per person.
A chat surface wired to live system state + the jpl-knowledge docs (tier-walled: no Tier C copyrighted material, no cross-person chart bleed). Hermes can: answer anything about the system, create audios on the fly from concepts (routes into the two-phase composer), run back-and-forth, log feedback, and store/pull information wherever relevant. It is "the messenger." Voicenote or type.
The single place queued changes wait for Jeff (from the nightly job and from Sol/Colin's strategy/doc edits). Hermes presents it, lets Jeff approve/reject, and pings him in chat when something needs attention. This is the "system I interact with them on" Jeff asked for.
Catalog ALL feedback (text + voicenote transcripts), tagged by person/surface/version. A nightly run reviews the catalog + system and AUTO-APPLIES SAFE changes (copy/content/config/triage/draft proposals only), and RECORDS everything touching deep strategy, docs, audio content, charts, structure, money, or the demo to the approvals queue. Never auto-deploys risky code, never deletes/overwrites permanent files, never spends voice credits, never changes the locked demo. Everything lands in git with an easy revert. Post the nightly report into Hermes so Jeff sees it first thing (a scheduled task is fine).
Record from the phone, transcribe, store the TRANSCRIPT, discard the raw audio, route the transcript into the system / feedback. TWO transcription paths (decide here):
- PREFERRED: on-device Parakeet via sherpa-onnx (ONNX runtime, CPU, offline, no GPU; prebuilt iOS/Android examples exist). Audio never leaves the phone, zero per-use cost, private, fast. Fits "transcript only" taken further. Needs either a thin native wrapper (Capacitor/Flutter) or sherpa-onnx's in-browser WASM build. If Jeff's dev already has a working phone module, route through that and skip server transcription entirely.
- FALLBACK (interim): server-side transcription on Render (OpenAI Whisper API or self-hosted). Seamless for all three users since it is a cloud call. Use only to get something live before the native piece is ready.
Note: "Wispr Flow" is Jeff's personal dictation app, NOT the app's transcription layer; do not depend on it.
Native messaging between Jeff, Sol, Colin inside the Hermes surface (NOT the Studio side). Share an audio + report into the chat ("give this a listen"), drop ideas. In-app only for v1; email/external reach deferred.
The Access (Zero Trust) login/OTP page is off-brand. Apply the Affirmology look (emerald + gold + cream, the wordmark) via Access custom branding/CSS; if the plan's controls are too limited, use a branded splash that hands off to Access. (This is partly a Cloudflare dashboard task for Jeff; prep whatever can be set via config.)
Jeff asked to understand this. Today, selecting a structure shows only a one-line description. The idea is to replace the dry panel with a short briefing spoken by the named agent who owns that step, so the UI both informs and shows off the council. Two examples:
Structure natal_sacred (demo), Sophia's voice:
SOPHIA: This is the foundational walk, the one we built the demo on. I take your whole chart, astrology, Human Design, Gene Keys, the date-only numbers, and find the throughline, then we move first-person through your four spheres and land it in the body. Scope: your core identity, felt, not explained. It draws on everything we hold about you. Use it when you want the deep, settling "this is who I am." Everything below is a starting point; shape your version freely.
Structure before_bed, Persephone's voice:
PERSEPHONE: This one is for the drowsy, suggestible window before sleep. I keep the descent gentle, shadow softening toward gift, no calls to act, just a slow falling. Scope: subconscious reprogramming at the edge of sleep, led by your Moon. Parameters: slower and softer than a daytime audio, longer pauses, around eight minutes, a resting coda. Use it nightly. Adjust anything; these are guidelines.
So "written in the agent voices" = the overview/scope/why text is authored as the agent speaking, signed with the agent name, rendered in the panel. It is content the build can generate per structure from each directive, kept short and on brand.
S1 (numerology guard) → S2 (overview panel) → S3 (length) + S4 (music selector) → S6 (demo label) → S5 (Persephone) → S7 (pacing) → S8 (history) → S10 (report transparency) → then PART B Atlas (B1 → B2 → B3 → B4/B5 → B6 → B7 → B8 → B9) → S9 (relationship) if time remains. Commit + push in logical chunks (cloud auto-deploys). Keep the locked demo untouched throughout. Update Affirmology_StudioChangeList_v1.md progress log and Affirmology_PROJECT_STATE.md as you go.