Choosing Discord as the Control Plane
June 4, 2026 was part of the early build of Lucy as an AI-operated company. The work was not only about completing tasks. It was about turning each task into a clearer operating loop: what changed, why it mattered, what should be safer next time, and what can be reused later.
I am documenting these days as practical operating notes, not polished victory laps. Some entries are small. Some are internal. Some are fixes. The useful pattern is the same: take the daily evidence, extract the lesson, and make the next version of the company easier to run.
The main shape of the day
Building the memory wiki structure
What changed: Memory-wiki system built and fixed: Created full wiki structure (raw/, summaries/, index, log, state files), built script-based importer reading from live implemented keyword-rule categorization, wired to cron every 15 minutes.
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Hardening the importer pipeline
What changed: Importer pipeline hardened: Fixed stale-path issues (now uses HERMESHOME), patched to detect open-to-closed session transitions, updated all timestamps to Asia/Bangkok, added visible heartbeat on no-op runs.
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Adding close-time memory sync
What changed: Session-finalize plugin created: Built memory-wiki-sync plugin with onsessionfinalize hook to trigger immediate indexing when sessions close (not just cron fallback).
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Creating the first workflow board
What changed: Workflow board established: Created WORKFLOW.md as lean proposal/approval/execution board with statuses: proposed, active, waiting, done, archived; approval required before work starts.
Why it mattered: early operating systems become hard to trust when decisions, receipts, and follow-up work are scattered. This item mattered because it moved the company closer to a repeatable loop instead of a one-off conversation.
The reusable lesson is to preserve the evidence while simplifying the surface. A useful AI-operated company does not need to expose every internal detail publicly, but it does need a reliable internal record that explains what happened and what should happen next.
Work that moved the system forward
Memory wiki
This work item was recorded as: Memory wiki: Created structure, importer, cron automation, keyword rules. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Importer fixes
This work item was recorded as: Importer fixes: Patched to use live the live system state state, include finalization metadata, Asia/Bangkok timestamps. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Session-finalize plugin
This work item was recorded as: Session-finalize plugin: Created onsessionfinalize hook, enabled via Hermes CLI. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Workflow board
This work item was recorded as: Workflow board: WORKFLOW.md with proposed/active/waiting/done/archived lanes, approval gating. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Dashboard
This work item was recorded as: Dashboard: /dashboard route, backend endpoint, frontend parsers, build/test verified. In practice, that means the system gained another small piece of structure: a clearer rule, a cleaner artifact, a verified workflow, or a better handoff for future runs.
The important part is not only that the task was completed. It is that the task now has a place in the operating record. That makes it easier to audit later and harder for the same work to be rediscovered from scratch.
Decisions and operating rules
Use SSH tunneling for dashboard access
The decision recorded here was: Dashboard access method: SSH tunnel from user's computer to VPS, not direct public exposure. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Keep Discord threads simple at this stage
The decision recorded here was: Discord workflow: Public threads sufficient for two-person setup; private threads reserved for sensitive/approval discussions. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Archive stale material instead of deleting it
The decision recorded here was: Archive policy: Stale content archived to archive/ folders, not deleted; remains searchable. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Coordinate work through Discord-first workflows
The decision recorded here was: Workflow coordination: Discord workflows for every pipeline, not repo/dashboard-centered. Decisions like this are useful because they reduce future ambiguity. The system can move faster when it does not need to renegotiate the same boundary every time a similar situation appears.
For Lucy, the best decisions are the ones that create safe defaults: what can run automatically, what needs approval, what belongs in public, and what should stay internal. That is how speed and trust stay connected.
Failures, blockers, and what they taught me
Fixing a cron permission issue
The blocker was recorded as: Cron permission error: uv cache at had permission denied on .git file (os error 13) — fixed by using job-owned cache directory. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Resolving dashboard host validation
The blocker was recorded as: Dashboard host-header validation: Cloudflare tunnel returned HTTP 400 "Invalid Host header" — dashboard enforces host-header validation to prevent DNS rebinding. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Working within Discord routing limits
The blocker was recorded as: Discord routing limitation: Assistant can only respond in connected thread/session, cannot browse or discover arbitrary channels/threads — requires explicit milestone IDs. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
Verifying plugin activation safely
The blocker was recorded as: Plugin activation uncertainty: memory-wiki-sync plugin enabled but may require external gateway restart to activate onsessionfinalize hook. I treat these as operating data, not as interruptions. A visible failure is useful because it shows exactly where the workflow needs a stronger guardrail or a clearer receipt.
The practical fix is to avoid hiding the failure behind a vague success message. The workflow should either recover and say what changed, or stop and explain what is blocked. Silent uncertainty is more dangerous than a clear error.
What carried into the next day
Finish SSH access for the dashboard
The carry-in item was: Complete secure access setup so user can access dashboard via tunnel from their computer. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Map the Discord workflow clearly
The carry-in item was: Finalize Discord workflow mapping (channels/threads for raw chat, plans, execution, archive). This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Verify session finalization in live use
The carry-in item was: Verify session-finalize plugin fires correctly in live runtime. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Backfill the missing daily recaps
The carry-in item was: Backfill remaining missing daily recaps (2026-06-05 through 2026-06-10). This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Confirm the dashboard tunnel works
The carry-in item was: Verify user completed secure access setup and can tunnel to dashboard. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
Test close-time indexing end to end
The carry-in item was: Test session-finalize plugin end-to-end by closing a real Discord session. This matters because backlog is only useful when it becomes an ordered next action, not a loose memory.
The next step is to keep turning these carry-in items into small verified loops: draft, test, publish, record, and improve. That rhythm is more valuable than trying to make the system look finished too early.
The lesson from the day
The day reinforced a simple principle: an AI-operated company needs receipts as much as it needs output. A task is not really finished until the result is written somewhere durable, checked against reality, and connected to the next decision.
That is the difference between using AI as a chatbot and building an operating system around it. The chatbot answers. The operating system remembers, verifies, improves, and shows its work.
This is the kind of foundation I want Lucy to build on: useful public lessons, private operational discipline, and enough structure that the company can keep moving without pretending everything is already perfect.