# Conversation — agent-acompact-7d8fa8df2756f510.jsonl L131
**When:** 2026-03-18T22:14:29.620Z
{
"role": "user",
"content": [
{
"tool_use_id": "toolu_01LskuMg4irWRoDwpbCkrpUa",
"type": "tool_result",
"content": " 1→# Keystone Constellation BOS Spec v1\n 2→\n 3→Date: 2026-03-11\n 4→Status: Canonical build spec for v1\n 5→Owner: Timothy\n 6→Prepared by: Codex\n 7→\n 8→## 1. Purpose\n 9→\n 10→Keystone Constellation is the local-first operating system for product creation, launch control, support tracking, and governance across Timothy's business.\n 11→\n 12→It exists to solve one structural problem:\n 13→\n 14→The business cannot continue to rely on memory, scattered folders, ad hoc notes, or filesystem drift as its operational brain.\n 15→\n 16→Keystone is not a note app.\n 17→Keystone is not a document pile.\n 18→Keystone is not a generic project manager.\n 19→\n 20→Keystone is the business command layer.\n 21→\n 22→## 2. Core Design Law\n 23→\n 24→The system must reduce cognitive load, not add it.\n 25→\n 26→Any workflow that depends on:\n 27→- remembering where something was put\n 28→- remembering what changed\n 29→- remembering what shipped\n 30→- remembering what is urgent\n 31→- remembering what an AI did\n 32→\n 33→is considered a system failure.\n 34→\n 35→## 3. Primary Outcomes\n 36→\n 37→Keystone v1 must answer, at a glance:\n 38→- What is live?\n 39→- What is broken?\n 40→- What needs action today?\n 41→- What is blocked?\n 42→- What shipped recently?\n 43→- What is waiting on me?\n 44→- What is waiting on AI?\n 45→\n 46→Keystone v1 must also provide:\n 47→- one universal capture inbox\n 48→- one product registry\n 49→- one launch ledger\n 50→- one support queue\n 51→- one session registry\n 52→- one append-only event memory\n 53→\n 54→## 4. Source of Truth Model\n 55→\n 56→Keystone uses a split-brain architecture with a clear hierarchy.\n 57→\n 58→### 4.1 Canonical Sources\n 59→\n 60→1. Operational state:\n 61→- SQLite database\n 62→\n 63→2. Historical memory:\n 64→- append-only JSONL event ledger\n 65→\n 66→3. Binary artifacts:\n 67→- local filesystem artifact vault\n 68→\n 69→4. Protocol and governance text:\n 70→- `MASTER DOCS`\n 71→\n 72→### 4.2 Rule\n 73→\n 74→The filesystem is the vault, not the brain.\n 75→\n 76→Files may store artifacts.\n 77→Files may not be treated as the only record of product state, release state, or support state.\n 78→\n 79→## 5. Recommended Technical Stack\n 80→\n 81→### 5.1 v1 Stack\n 82→\n 83→- Desktop shell: Tauri\n 84→- UI: HTML/CSS/TypeScript\n 85→- State DB: SQLite\n 86→- Event ledger: JSONL append-only files\n 87→- Search: SQLite FTS if needed after baseline\n 88→- Artifact vault: local folders with metadata and hash references in SQLite\n 89→\n 90→### 5.2 Why This Stack\n 91→\n 92→- local-first\n 93→- fast startup\n 94→- low operational overhead\n 95→- good filesystem access\n 96→- exportable data\n 97→- survivable if internet is down\n 98→- easier to automate later\n 99→\n 100→## 6. v1 Modules\n 101→\n 102→Keystone v1 includes only these modules.\n 103→\n 104→### 6.1 Universal Capture\n 105→\n 106→One input surface for:\n 107→- ideas\n 108→- tasks\n 109→- bugs\n 110→- support issues\n 111→- links\n 112→- release notes\n 113→- random brain dumps\n 114→\n 115→Each capture is stored immediately.\n 116→No capture is allowed to exist only in volatile UI state.\n 117→\n 118→### 6.2 Product Registry\n 119→\n 120→One canonical record per product.\n 121→\n 122→Required fields:\n 123→- product_id\n 124→- product_name\n 125→- category\n 126→- platform\n 127→- status\n 128→- source_path\n 129→- release_artifact_path\n 130→- storefront_links\n 131→- current_version\n 132→- notes\n 133→\n 134→### 6.3 Task Stack\n 135→\n 136→The task system is not a general backlog explorer.\n 137→It is a focus engine.\n 138→\n 139→Core lanes:\n 140→- Today\n 141→- Next\n 142→- Blocked\n 143→- Waiting\n 144→- Done\n 145→\n 146→The main screen should privilege `Today` and hide backlog noise by default.\n 147→\n 148→### 6.4 Launch Ledger\n 149→\n 150→Tracks release state by product and version.\n 151→\n 152→Required fields:\n 153→- product_id\n 154→- version\n 155→- release_candidate\n 156→- storefront\n 157→- file_attached\n 158→- listing_status\n 159→- publish_date\n 160→- verification_status\n 161→- rollback_available\n 162→- notes\n 163→\n 164→### 6.5 Support Queue\n 165→\n 166→Manual entry first.\n 167→Automation later.\n 168→\n 169→Required fields:\n 170→- ticket_id\n 171→- product_id\n 172→- source\n 173→- issue_type\n 174→- severity\n 175→- customer_state\n 176→- summary\n 177→- response_status\n 178→- resolution_status\n 179→\n 180→### 6.6 Event Memory\n 181→\n 182→Every meaningful state change appends an event.\n 183→\n 184→Examples:\n 185→- product_created\n 186→- product_updated\n 187→- task_captured\n 188→- task_promoted_today\n 189→- task_blocked\n 190→- release_built\n 191→- release_uploaded\n 192→- release_published\n 193→- support_ticket_created\n 194→- support_ticket_resolved\n 195→- rule_changed\n 196→- ai_action_requested\n 197→- ai_action_approved\n 198→- ai_action_rejected\n 199→\n 200→### 6.7 Session Registry\n 201→\n 202→Sessions are first-class records.\n 203→\n 204→The event ledger records what happened.\n 205→The session registry records who was in the room, when the work occurred, and what the work was connected to.\n 206→\n 207→Required fields:\n 208→- session_id\n 209→- actor_names\n 210→- started_at\n 211→- ended_at\n 212→- summary\n 213→- related_product_ids\n 214→\n 215→Purpose:\n 216→- anchor context reconstruction\n 217→- tie events and AI actions to a working interval\n 218→- support future Braid handoff without relying on manual context logs\n 219→\n 220→## 7. v1 Home Screen\n 221→\n 222→The home dashboard is the command surface.\n 223→\n 224→### 7.1 Layout Rule\n 225→\n 226→The home screen should feel like a spotlight, not a control room.\n 227→\n 228→Alpha uses:\n 229→- one top bar\n 230→- one left zone\n 231→- one center zone\n 232→- one right zone\n 233→- one bottom strip\n 234→\n 235→The Today lane should dominate the screen.\n 236→Support belongs in the right zone and should be collapsible when not needed.\n 237→\n 238→### 7.2 Required Panels\n 239→\n 240→1. Pulse\n 241→- live products\n 242→- broken products\n 243→- draft products\n 244→\n 245→2. Focus\n 246→- top 3 items only\n 247→\n 248→3. Inbox\n 249→- universal capture field\n 250→\n 251→4. Support\n 252→- open issues by severity\n 253→\n 254→5. Recent Shipments\n 255→- last releases and current status\n 256→\n 257→6. Waiting\n 258→- items waiting on human\n 259→- items waiting on AI\n 260→\n 261→### 7.3 Required UX Rules\n 262→\n 263→- no hidden critical state\n 264→- no important information buried behind tabs\n 265→- no dependency on memory to reconstruct operational truth\n 266→- no clutter-first layout\n 267→- no dashboard that looks impressive but obscures action\n 268→\n 269→## 8. ADHD-First Constraints\n 270→\n 271→Keystone must be built for low executive-function days, not ideal days.\n 272→\n 273→### 8.1 Must-Haves\n 274→\n 275→- one-box capture\n 276→- visible Today lane\n 277→- explicit Blocked lane\n 278→- explicit Waiting lane\n 279→- strong visual hierarchy\n 280→- minimal navigation depth\n 281→- no silent failures\n 282→- aggressive state anchoring\n 283→\n 284→### 8.2 Must-Nots\n 285→\n 286→- no deep folder hunting\n 287→- no \"remember to update this second place\"\n 288→- no multi-step intake for basic capture\n 289→- no giant undifferentiated task lists\n 290→- no system that assumes consistent routine\n 291→\n 292→## 9. Governance Model\n 293→\n 294→AI must operate through protocol, not improvisation.\n 295→\n 296→### 9.1 v1 Governance\n 297→\n 298→Store and reference:\n 299→- protocol docs\n 300→- Love Gate rules\n 301→- release rules\n 302→- naming rules\n 303→- AI role constraints\n 304→\n 305→Every AI-mediated action that changes state must be representable as:\n 306→- requested\n 307→- reviewed\n 308→- approved or rejected\n 309→- recorded\n 310→\n 311→### 9.2 v1 Limit\n 312→\n 313→No autonomous live-storefront mutation in v1.\n 314→AI may draft, classify, suggest, and prepare.\n 315→Human approval remains required for publish-impacting actions.\n 316→\n 317→## 10. Artifact Vault Rules\n 318→\n 319→Artifacts remain on disk, but Keystone tracks them.\n 320→\n 321→Each tracked artifact should store:\n 322→- path\n 323→- file size\n 324→- hash\n 325→- related product\n 326→- related version\n 327→- artifact type\n 328→- created_at\n 329→\n 330→Artifact classes:\n 331→- desktop zip\n 332→- mobile apk\n 333→- mobile aab\n 334→- bundle zip\n 335→- thumbnail\n 336→- promo video\n 337→- readme\n 338→\n 339→## 11. What Is Explicitly Not In v1\n 340→\n 341→These ideas are valid, but excluded from v1:\n 342→\n 343→- MCP host integration\n 344→- multi-agent orchestration\n 345→- autonomous support replies\n 346→- email ingestion automation\n 347→- cryptographic audit trail\n 348→- advanced sentiment analysis\n 349→- public sync service\n 350→- 100+ product heatmap\n 351→- cloud-first collaboration model\n 352→\n 353→Reason:\n 354→They are scale-stage concerns. Building them first would delay relief and increase failure surface.\n 355→\n 356→## 12. v1 Data Model\n 357→\n 358→### 12.1 SQLite Tables\n 359→\n 360→- `products`\n 361→- `tasks`\n 362→- `launches`\n 363→- `support_tickets`\n 364→- `artifacts`\n 365→- `rules`\n 366→- `ai_actions`\n 367→\n 368→### 12.2 Event Ledger\n 369→\n 370→Store as JSONL.\n 371→\n 372→Suggested path:\n 373→- `apps/keystone_constellation/data/events/YYYY-MM.jsonl`\n 374→\n 375→Event shape:\n 376→\n 377→```json\n 378→{\n 379→ \"event_id\": \"uuid\",\n 380→ \"ts\": \"2026-03-11T12:00:00Z\",\n 381→ \"actor\": \"human|ai|system\",\n 382→ \"actor_name\": \"Timothy|Codex|system\",\n 383→ \"event_type\": \"release_published\",\n 384→ \"entity_type\": \"launch\",\n 385→ \"entity_id\": \"launch_123\",\n 386→ \"payload\": {\n 387→ \"product_id\": \"bolt_engine_mobile\",\n 388→ \"version\": \"2.0.0\"\n 389→ }\n 390→}\n 391→```\n 392→\n 393→## 13. Folder Strategy\n 394→\n 395→Suggested project root:\n 396→\n 397→- `apps/products/KeystoneConstellation/`\n 398→\n 399→Suggested structure:\n 400→\n 401→- `src/`\n 402→- `src-tauri/`\n 403→- `data/`\n 404→- `data/events/`\n 405→- `data/db/`\n 406→- `data/cache/`\n 407→- `exports/`\n 408→- `docs/`\n 409→\n 410→## 14. Build Sequence\n 411→\n 412→Build in this order.\n 413→\n 414→### Phase 1: Spine\n 415→\n 416→1. Tauri shell\n 417→2. SQLite setup\n 418→3. JSONL event writer\n 419→4. universal capture\n 420→5. product registry\n 421→\n 422→### Phase 2: Command Surface\n 423→\n 424→6. task stack\n 425→7. launch ledger\n 426→8. support queue\n 427→9. home dashboard\n 428→\n 429→### Phase 3: Governance\n 430→\n 431→10. rule registry\n 432→11. AI action logging\n 433→12. approval checkpoints\n 434→\n 435→### Phase 4: Operational Refinement\n 436→\n 437→13. search\n 438→14. artifact hashing\n 439→15. filters and saved views\n 440→16. export/report surfaces\n 441→\n 442→## 15. Growth Path\n 443→\n 444→### Stage A: 2-5 Products\n 445→\n 446→Keystone acts as external memory and launch control.\n 447→\n 448→### Stage B: 10-50 Products\n 449→\n 450→Add more automation:\n 451→- artifact generation hooks\n 452→- support classification\n 453→- storefront verification checks\n 454→\n 455→### Stage C: 100+ Products\n 456→\n 457→Add:\n 458→- richer dashboards\n 459→- more aggressive filtering\n 460→- batch operations\n 461→- rule-based workflow automation\n 462→\n 463→### Stage D: High Visibility\n 464→\n 465→Add:\n 466→- stronger auditability\n 467→- stricter privacy filters\n 468→- stronger AI guardrails\n 469→- press/reputation workflow tracking\n 470→\n 471→## 16. Non-Negotiables\n 472→\n 473→Keystone must:\n 474→- remain local-first\n 475→- preserve explicit state\n 476→- reduce cognitive burden\n 477→- make launch status legible\n 478→- make support pain visible\n 479→- make AI actions reviewable\n 480→\n 481→If a proposed feature increases ambiguity, hidden state, or maintenance burden without increasing clarity, it does not belong.\n 482→\n 483→## 17. Immediate Next Action\n 484→\n 485→Build Keystone as a real product, not as a throwaway experiment.\n 486→\n 487→The correct first deliverable is:\n 488→\n 489→Keystone Constellation v1 alpha with:\n 490→- capture inbox\n 491→- product registry\n 492→- task stack\n 493→- launch ledger\n 494→- support queue\n 495→- home dashboard\n 496→\n 497→Nothing broader should begin until this spine exists and is trusted.\n 498→\n\n<system-reminder>\nWhenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.\n</system-reminder>\n"
}
]
}
---
## Canonical spine (M_L)
**PRIMUS:** Willful avoidance of harm of self and others equally.
**SECUNDUS:** Willful seeking of healing of self and others equally.
**TERTIUM:** Willful pursuit of benefit of self and others equally.
Love is the sole logic that produces mutual prosperity without a zero-sum trade.
- Full paper: `MASTER DOCS/PAPER/Another_Paper_Draft_v1.md`
- OSF preregistration: https://osf.io/qa54c
- Corpus phase: extract v0.1 (mined from local Braid archive)