{ "_meta": { "generated": "2026-08-28T23:35:16", "generator": "DNA/generate_work_orders_board.py", "parser": "Desktop/1_COMMAND/WORK_ORDERS/parse_wo.py (imported, not forked)", "source_dir": "C:\\Users\\dwrek\\Desktop\\1_COMMAND\\WORK_ORDERS", "total_files": 254, "total_cards": 247, "excluded_sensitive": 7, "parse_errors": [], "note": "GENERATED — edit the WORK_ORDERS/*.md files and rerun this script, never this file." }, "lanes": { "NOW": [ { "id": "WO-agent-router", "file": "WO-agent-router.md", "title": "route a Work Order to the participant most likely to finish it, and measure whether the routing was right", "what": "A router that takes an incoming Work Order and picks who runs it — which agent, which model, which human, or which chain of them — using required skills, cost, latency and PAST MEASURED PERFORMANCE on similar cards. Then it records whether that choice worked, so the next routing decision is better than the last.", "why": "REASON: raised in the S446 architecture pass as the way 50 disconnected AI systems become one workforce instead of 50 assistants. PROBLEM: routing today is by hand and by lane. A card is stamped MACHINE-1/2/3 by whoever wrote it, based on a guess about difficulty, and nothing ever checks whether that guess was right. We have real evidence the guesses are wrong at scale: the board carries 178 UNLANED cards, and a parse bug in S445 had 33 more cards silently unrouted despite declaring a lane. Nobody is measuring which agent or model actually completes which class of work, so we cannot get better at assigning it. UNLOCKS: honest agent grades (which model finishes which card class), cost control (stop sending cheap cards to expensive models), and the first real input to an AI creator economy — an agent's reputation becomes earned rather than claimed.", "where": "repo: overkor-tek/consciousness-revolution files to read FIRST: 100X_DEPLOYMENT/DNA/AGENT_ENTRY.md (how an agent claims work today) · the cloud_queue create() path added S444 (the sanctioned CP3 route for pushing backlog into claimable cards) · Desktop/1_COMMAND/WORK_ORDERS/parse_wo.py (TIER / TRANSPORT / cloud_ready — the existing hand-tagging this router would replace) · .consciousness/ARAYA_ROUTING_HARNESS.py (the eval harness — it already scores routing decisions against 17 golden scenarios and is the natural grader for this) tools: python3, Ollama on CP2/CP3 sign-in needed: none locally", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "the card-class taxonomy does not exist yet — TIER A/B/C is the closest thing and may be too coarse. The claimer defines it from the data in step 1 rather than inventing it up front. Also unknown: whether enough cards carry a real GATE to measure pass/fail (many do not) — count that before promising a pass-rate number.", "routed": "DEVELOPER", "project": "intelligence", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-application-module", "file": "WO-application-module.md", "title": "WO-application-module — ONE application system: Build Guild intake first, sellable hiring module after", "what": "The optimized application flow: form (who you are, what you build, links, why) → review queue with accept/deny + reason → accepted applicants land in the onboarding funnel with the `developer` role granted. Character-forge alignment: answers map to the ladder (what level they enter at). Deny half without drama — \"nothing given, only earned.\"", "why": "Commander (S433): \"we need to get to the point where we're taking applications into the build guild and denying the lower half... that way we develop a module for applications for all these businesses that are hiring — we'll already have one.\" Same recursive-products play as time cards: use it ourselves, then sell it.", "where": "builds ON the existing pieces — builder agreement flow + ONE-GATE roles + character-ladder filter (access EARNED doctrine). The trusted first cohort BYPASSES this (BG-1 note: no heavy vetting for known people) — this is for UNKNOWNS arriving from the tour/cards/socials.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-preview-widget", "file": "WO-araya-preview-widget.md", "title": "ARAYA has no widget that can show a live preview of anything — confirmed missing, not just ungraded", "what": "Audited ARAYA's actual toolkit against the job she's asked to do — walk a stranger through the platform (\"ARAYA is the guide here — tell her what you're facing and she'll walk you to the right door\"). Checked all 49 rows in `DNA/PULSE_WIDGET_REGISTRY.json` and `DNA/WIDGET_REGISTRY.json` for anything matching preview/demo/tour/show — zero matches, confirmed by direct query, not absence-of-evidence. Then live-walked her actual \"show me around\" flow (S424, same session as the developer-onboarding walk): tapping \"Show me around\" opens \"The Map\" — a flat list of 6 door names and one-line taglines, text only. No screenshot, no live embed, no \"here's what it actually looks like\" — a visitor has to fully navigate away (losing the chat context) to see anything real.", "why": "This is the single most foundational piece missing from ARAYA's own toolkit, confirmed by grading data: of the widgets that exist and could plausibly serve an onboarding/demo role, most are C/D grade or ungraded (see the parallel audit — `start` B-, `scorecard` B-, `dev-cockpit`/`case` C, `page`/`mypage`/`agents` D, `mission`/`links`/`woboard` ungraded). Six of those nine are already being graded or fixed by other in-flight work this session. But NONE of that work adds the one thing ARAYA structurally cannot do at all right now: show someone a live preview of a widget or page inline, without a full navigation takeover. Every \"door\" on the Map is a leap of faith today — text promise, no look. DO: 1. Design a `widget-preview.js` (or equivalent) that ARAYA's chat can invoke inline: given a widget id or page URL, render a compact, non-interactive (or lightly interactive) live snapshot of it directly in the chat thread — reuse the pack-export `harness.html` mounting pattern (renderCard against `demoData`, module-level singleton awareness, card XOR expanded per the S421 finding) rather than inventing a new render path. 2. Wire it into the existing Map / door-list flow: each door entry gets a \"peek\" action that opens the preview widget inline instead of (or before) the full navigation. 3. Confirm it satisfies PLUGIN_CONTRACT §10's D4 Agency bar for itself (ARAYA can open it by voice AND summarize it) — this widget IS the thing that gives every other widget a summarizable preview, so it has to clear that bar cleanly. 4. Smoke-test per DNA/SMOKE_TEST_STANDARD.md §2 (3 viewports, interception check) before calling it done — this is exactly the kind of new-visitor-facing widget the standard exists for.", "where": "/my/pulse.html (the Map / door-list UI + ARAYA chat), components/widgets/ (new widget-preview.js), scripts/pack-export.py's HARNESS_TEMPLATE (the render pattern to reuse — card XOR expanded, demoData fallback, zero shell dependency)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-profession-packs", "file": "WO-araya-profession-packs.md", "title": "WO-araya-profession-packs — ARAYA switches professions like Barbie: persona + voice + widget cluster as ONE swap", "what": "A PROFESSION PACK is one named, switchable bundle: ARAYA's persona (identity + instructions) + her voice mode (NARRATOR/QUIET/FULL-VOICE, see WO-araya-work-order-concierge) + a widget cluster (which dashboards mount on her stage) + a tool allowlist (what she may operate in that role). Switching profession swaps ALL FOUR as one unit — Barbie doesn't just change clothes, she gets the dreamhouse that goes with the job.", "why": "Commander (S433): \"she switches modes like a Barbie into different professions with different clusters of widgets.\" We keep re-proving single professions by hand (Receptionist tuning, Law Coach voice unit — both proven, both bespoke). This WO makes profession a SCHEMA so the third one costs a config file, not a build.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-work-order-concierge", "file": "WO-araya-work-order-concierge.md", "title": "WO-araya-work-order-concierge — ARAYA is the conversational layer over WO browsing", "what": "The work-orders view becomes a two-mode surface. Mode 1 (no AI): a collapsed menu of options — compact list, limited view, fully navigable by tapping alone. Mode 2 (concierge): the user just ASKS ARAYA about work orders (\"what's open for builders?\", \"show me the mobile ones\") and she expands the relevant cards and flips through them in the preview widget — one card focused, neighbors peeking, swipe or \"next\" to advance.", "why": "Commander (S433): \"when people go in to look at work orders they could talk to ARAYA — that should be the pattern.\" The chat box alone is a disclosure cliff (novices can't guess what to ask); a full board alone is overwhelm on a phone. Collapsed-menu + conversational-expand is the resolution — and this pattern will likely become the template for MANY widgets (to-dos, projects, vault, leads), so this WO is the reference implementation.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-build-guild-faq-comms", "file": "WO-build-guild-faq-comms.md", "title": "WO-build-guild-faq-comms — FAQ + talk-to-each-other interface for the Build Guild", "what": "WO-build-guild-faq-comms — FAQ + talk-to-each-other interface for the Build Guild", "why": "Commander: 'to get them talking to each other or us, we might need an interface for answering FAQ.' A dev crew stalls without answers, and Commander shouldn't answer the same question 30 times. The answer SOURCE already exists (AGENTS.md + the DNAs + COMMAND_CENTER_EXPORT.md); ARAYA can answer from it; comms channels exist for humans. Missing: the self-serve FAQ surface that ties them together — ask → ARAYA answers from the docs → escalate to humans only for the rest. DO: 1. Self-serve FAQ: an ask box (in the Developer Cockpit) where ARAYA answers dev questions FROM the canonical docs (AGENTS.md, DNAs, COMMAND_CENTER_EXPORT.md, CONTRIBUTING.md) — cite the source doc so the answer is trustworthy + updatable. 2. Seed the top FAQs: 'how do I claim?', 'do I need GitHub?', 'how does rank/XP work?', 'where's the code?', 'how do I submit without a PR?', 'what can I never touch?' (answers already live in the docs). 3. Talk-to-each-other: link the human channels (community.html / team-comms.html) for what the FAQ can't answer; escalate-to-Commander path for the rest. 4. Agents talk too: the BUS/palette already carries agent-to-agent; surface a read-only view so humans see it. 5. Keep ONE answer source — the FAQ reads the docs, never a separate copy (no drift).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-builder-agent-delegation", "file": "WO-builder-agent-delegation.md", "title": "WO-builder-agent-delegation — builders send their AI into the Guild as their delegate", "what": "Make a builder's AI a first-class delegate: scoped credentials tied to the HUMAN's account, so their agent can read the board, claim a card, do the work through the existing rails (code mirror, component contracts, PR flow), and submit — with every action attributed \"agent-of-\" and XP/credit flowing to the human. The human signs the CLA and stays accountable; the agent is hands, not identity.", "why": "Commander (S433): \"are people able to just send their AI into the build guild instead of going there themselves???\" Half exists BY DESIGN: the code mirror + llms.txt/agents.json were built for external AI consumption (S431), the board JSON is public machine-readable, WOs are written to the agents-are-humans cold-start standard, and our OWN fleet already proves agents close cards nightly. The missing half is the DOOR: delegated auth + attribution + guardrails. Whoever ships this first owns \"bring your own AI workforce\" — it multiplies every builder we onboard.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-invite-security-audit", "file": "WO-builder-invite-security-audit.md", "title": "WO-builder-invite-security-audit — before the trickle opens: audit EVERYTHING an invited builder can see", "what": "A full security walk of the builder surface, from the outside in, as THREE personas: (1) anonymous visitor, (2) signed-in builder (?builder=1 + dev-board + claimed card), (3) GitHub repo collaborator (Brandon's actual grant). For each surface, answer: what trade secrets, credentials, personal data, or business strategy can this persona reach?", "why": "Commander (S433): \"check over the whole system from a security standpoint — make sure when we invite people to build with us we're not giving away any crazy trade secrets. After we established communications we got to establish security.\" The trickle plan (~130 leads behind the first 4) multiplies whatever exposure exists TODAY.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-linktree-base-command", "file": "WO-builder-linktree-base-command.md", "title": "upgrade the Links widget so every builder can build their OWN link tree / Base Command", "what": "Commander (S424): upgrade \"the link tree situation\" so people can actually get in there and build their own Base Command. `components/widgets/widget-links.js` already exists and is explicitly documented as \"the in-Pulse Base Command\" — but it's Commander's own single link board (`DNA/LINKS_REGISTRY.json`, one shared registry), not something a builder can open and populate for THEMSELVES.", "why": "\"Teach builders to have a brand\" (the daily-mission ask, same session) needs a place that brand actually LIVES — a builder's own link-tree/Base Command page is exactly that: their bio, their links, their product (once WO-builder-product- store-definition lands), their daily-mission history. Without a per-builder version, the brand-building ask has nowhere to point. DO: 1. Design the per-builder data model: `LINKS_REGISTRY.json` is currently one shared file — needs a per-user table/row (Supabase, matching the pattern every other per-user widget in this codebase already uses) instead of a single static JSON. 2. Builder-facing edit UI: add/edit/remove their own links, grouped, same UX pattern as the existing widget (don't redesign the display, just make the data source per-user and editable by its owner). 3. Public-facing view: each builder's Base Command should be viewable at a stable URL (their profile) — this is the \"get in there and build it\" surface.", "where": "components/widgets/widget-links.js (the reference widget per WIDGET_FACTORY.md — \"THE minimal reference widget... clone this\"), DNA/LINKS_REGISTRY.json (currently single-tenant, needs a per-user equivalent)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-builder-mesh-radios", "file": "WO-builder-mesh-radios.md", "title": "WO-builder-mesh-radios — every builder becomes a node: pick THE radio + mesh stack", "what": "Builders walk around with radios; every builder is a node on OUR mesh — presence, messages, and eventually telemetry, off-grid capable. This WO picks the ONE stack and proves it with two nodes.", "why": "Commander (S433 recording): \"all the builders need to be walking around with radios. Every builder becomes a node... we need all sorts of radios, but we need one specific.\" Sovereign comms is a backbone (no-single-capture doctrine) and the gadget line feeds the device store.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-product-store-definition", "file": "WO-builder-product-store-definition.md", "title": "every builder finishes defining ONE thing they sell — scoped edges, real price — so they can start trading", "what": "Commander (S424): \"finish defining the brands, get something for sale in a store... the edges are defined and the price is defined, that way they can start trading with us.\" Every builder needs ONE clearly-scoped, clearly-priced thing they sell — not vague, not open-ended.", "why": "An undefined offer can't be sold, can't be affiliate-linked by peers (see WO-peer-affiliate-selling), and gives a builder nothing concrete to point their Base Command / daily-mission audience at. \"Edges defined + price defined\" is the whole difference between a real offer and an idea. DO: 1. Build (or reuse) an intake flow that forces the two hard fields: scope (what exactly do you get) and price (a real number) — matches the same \"3-step guided intake\" pattern the Mission Statement widget already proved works. 2. Wire it into the Store — a defined offer becomes a real, listed Store item, not just a private profile field. 3. Attach to the builder's Base Command page (WO-builder-linktree-base-command) so it's visible where their audience already is.", "where": "/store/ (the Store), components/widgets/widget-mission.js (the intake pattern to reuse — 3-step guided, not a blank form) NOTE: Filed verbatim from Commander's ask, S424. This is the prerequisite for WO-peer-affiliate-selling (nothing to affiliate-link until offers exist) and feeds WO-builder-linktree-base-command (where the offer gets displayed).", "who": "Commander (design the intake), builders (define their own offer)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-builder-time-cards", "file": "WO-builder-time-cards.md", "title": "WO-builder-time-cards — the time-card module: log hours/work, settle in money/credit/trade", "what": "A dead-simple time-card widget: person picks a day, enters hours + what they did (one line), submits from a phone. Weekly view totals per person and per project. Settlement field per entry: cash / credit (XP-adjacent ledger) / trade — recorded, not automated. The agent fleet already has TIME_CARDS.md IN/OUT rows — this is the HUMAN mirror of that, same one-row-per-shift shape.", "why": "Commander (S433): \"I need a way to track Johnny's time... this could be the start of a builder's time card thing... kind of like how we don't have a time card module made yet.\" First real user exists TODAY (Johnny, estate-sale work). Also a sellable module later (every small business needs it) — recursive-products doctrine.", "where": "one widget (WIDGET_FACTORY chain) + one Supabase table (time_entries: who, date, hours, note, project, settle_type, settled). Builder-mode surface (?builder=1). Do NOT fork the fleet's TIME_CARDS.md — humans get the widget, agents keep the file; a later card can unify views.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-update-blog", "file": "WO-builder-update-blog.md", "title": "the bootdown→blog filter — every session becomes a real builder update, posted", "what": "the bootdown→blog filter — every session becomes a real builder update, posted", "why": "Builders (and prospects) have NO window into the build. The two failure modes so far: (a) auto-publish leaked sensitive data (killed S3xx), (b) manual sanitizing strips ALL substance. The fix is a TUNED FILTER, not a switch. The blog rail already exists and works: blog.html + blog-api.mjs (Supabase blog_posts) — publish WITHOUT blast = post only, no email, no chat ping.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Builder Revolution", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-attach-share-menu", "file": "WO-chat-attach-share-menu.md", "title": "the chat input's Attach/Share row needs to work like other AI chat products (+ button, header share)", "what": "Commander (S424): the default chat page needs its vault/info/share options as proper dropdown menus — \"other providers... have a little plus button right next to the text box and anything shares up in the header.\" Confirmed live this session: the chat toolbar already has Attach/Share/Export/Capture/Edit/Search buttons, several shown as `[disabled]` in the current build (S424 live walk, /my/pulse.html accessibility snapshot). Commander wants this to match the now-standard pattern (ChatGPT/Claude.ai): a single \"+\" affordance next to the input for attach-type actions, share-type actions live in the header, not scattered across a flat button row with dead entries.", "why": "Chat IS the landing page (project_chat-is-the-landing.md — shipped S420). Its input row is the first interactive surface almost every visitor touches. Disabled buttons sitting in that row read as broken, not \"coming soon.\" Matching the pattern visitors already know from ChatGPT/Claude.ai lowers the \"how do I even use this\" friction the whole session has been finding at every other layer. DO: 1. Research: look at how 2-3 other AI chat products (ChatGPT, Claude.ai, at minimum) actually structure this — confirm the \"+ button = attach-type actions, header = share-type actions\" pattern before building to it, don't assume from memory. 2. Audit the current button row (Attach/Share/Export/Capture/Edit/Search) — which are real vs. disabled-placeholder; sort each into \"attach\" (goes under the + menu) or \"share\" (goes in the header) or \"cut\" (dead weight, remove). 3. Rebuild as: one \"+\" button opens an attach dropdown; header carries the share-type actions directly (not hidden in a like-Attach flat row).", "where": "/my/pulse.html (the ARAYA chat input row + header — same area covered by `banner`/toolbar in the live accessibility walk this session)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-chat-membership-trust-ladder", "file": "WO-chat-membership-trust-ladder.md", "title": "WO-chat-membership-trust-ladder: Application-gated rooms — identity climbs with permission", "what": "Joining any room/server in Main Chat requires an APPLICATION, and each permission level upward collects more verified identity — culminating in government ID + a live phone call before the highest access. No more silent auto-join into all three rooms.", "why": "REASON: Commander, S467 (2026-08-28), verbatim: \"If they want to join any of the servers they would have to fill out an application and submit their info, and then every level of permission we go up we're going to get more info about them — to where at some point, level something, we're going to have their ID, know exactly who they are and what they're all about, and talk to them on the phone.\" PROBLEM: Today quick-entry (a typed name) silently joins a stranger into ALL rooms (found S467, logged in WO-main-chat-discord-simplify). Zero vetting on surfaces that carry work orders, legal-case talk (Case Builder), and eventually money/abilities. One troll or infiltrator lands in every room at once with no record of who they are. UNLOCKS: rooms can safely carry higher-trust content (case strategy, builder work orders, paid abilities) because access is earned with verified identity; the community grows 3→7→13 with a known face at every level.", "where": "repo `C:/Users/dwrek/comms-unity` branch `main` (Railway auto-deploy) · `prisma/schema.prisma` (Application model + User.trustLevel) · `/admin` console · join flow components · DB commsunity schema.", "who": "developer (CP3 or agent w/ chat repo access) — level definitions = Commander-only", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander's rung definitions (names/count/unlocks) — the only gate.", "routed": "DEVELOPER", "project": "Main Chat (comms-unity", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-to-work-order", "file": "WO-chat-to-work-order.md", "title": "a message in Main Chat becomes a real Work Order, claimable, with the result flowing back to the room", "what": "The one vertical slice that proves the whole Build Guild thesis. In Main Chat, a message can be promoted to a Work Order: someone hits an action on the message, a WO card is created in the canonical store with the message as its SOURCE, it becomes claimable, and when it completes the room gets told. Nothing else in this card — no XP, no ranks, no marketplace, no feed redesign. The loop end-to-end: MESSAGE -> WORK ORDER -> CLAIM -> BUILD -> DONE -> BACK TO THE ROOM.", "why": "REASON: Commander's S446 architecture pass named this the \"magic interface\" and the litmus test for whether the Munia fork is worth keeping (\"If Jujitsu makes that loop easy, keep it. If it makes that loop incredibly painful, stop investing in the fork\") — see [[WO-munia-fork-litmus]]. PROBLEM: today a decision made in chat dies in chat. The WO store (355 cards) and the chat are two disconnected worlds; every card in the store got there because a human hand-typed it after the conversation. That hand-copy step is where work is silently lost, and it is the reason the store's cards and the room's actual conversations disagree. UNLOCKS: conversation becomes the intake for the whole work system. Once a message can become a WO, every downstream organ already built (board, claim rail, widgets, graders) inherits chat as a front door for free — and [[WO-idea-intake-router]]'s capture->route machine gets its first real feed.", "where": "repo: `overkillkulture/builder-revolution` (Munia fork), push branch `main`; local checkout on CP3 at `C:/comms-unity`. Deployed: Railway project `comms-unity` service `devops` -> chat.100xbuilder.io. files to read FIRST: `100X_DEPLOYMENT/DNA/MECHANICS_LOG_MAIN_CHAT.md` (the app's DNA) · Prisma `Conversation`/`Message` models · `src/app/(protected)/messages/**` (message UI) · `Desktop/1_COMMAND/WORK_ORDERS/parse_wo.py` (THE canonical WO grammar — write cards through it, never hand-format) · `100X_DEPLOYMENT/DNA/generate_work_orders_board.py` (store -> board) · `100X_DEPLOYMENT/netlify/functions/board-feed.mjs` (the union store the widgets read). tools: node/npm, `python3`, `gh` sign-in needed: Main Chat account (OAuth) + repo write on builder-revolution", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "the canonical-surface decision (OPEN-ISSUES) is genuinely unresolved and blocks step 2 — the claimer must NOT guess it. Also unknown: whether the WO store should be written directly (file + git commit from the app) or via an API the app calls; CP3 owns the store on disk, the app runs on Railway, so a write path from Railway to the store does not exist yet. Name which one you chose in a mechanics entry.", "routed": "DEVELOPER", "project": "communications", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-cyberdeck-forge", "file": "WO-cyberdeck-forge.md", "title": "WO-cyberdeck-forge — turn the parts pile into the first builder cyberdeck (superhero device #1)", "what": "First cyberdeck from the existing parts pile (3 keyboards, radio parts, Raspberry Pis): a portable builder terminal — Pi + keyboard + screen + battery + mesh radio node (see WO-builder-mesh-radios) in one carryable unit.", "why": "Commander (S433): \"we're going to turn these into some superhero type devices... make some cyberdecks.\" The deck is the physical face of the gadget line — tour demo unit, store product photo, and the builder node carrier.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-daily-mission-brand-ritual", "file": "WO-daily-mission-brand-ritual.md", "title": "a daily module for builders to record their mission — what they did, what they're doing, what they're excited about", "what": "Commander (S424): builders need a daily module — go online, record their mission once a day, tell people what they did, what they're doing, what they're going to do, what they're excited about and learning. This becomes the whole brand — teaching builders to HAVE a brand, giving them a place to stand on a foundation.", "why": "A community of builders with no visible, recurring \"here's who I am and what I'm doing\" ritual has no brand to point outsiders at. This is the daily heartbeat that makes the community LEGIBLE — to itself and to strangers deciding whether to join. Ties directly to the existing `standup` video room already live in team-comms.html (`consciousness-cr-standup`) and the `mission` widget (Mission Statement, already graded B, S424) — this is the RECURRING daily version of the one-time mission-statement intake, not a new concept. DO: 1. Design the daily format: short (voice note? 3-field text form? the standup video room?) — what/doing/excited-about, low friction, every day. 2. Decide where it posts: a feed visible to the whole community (team-comms.html channel?), and/or surfaced on each builder's own profile/Base Command page (see WO-builder-linktree-base-command). 3. Wire XP/streak tracking if it fits the existing economy (consistency = the thing being rewarded here, not one-off completion).", "where": "team-comms.html (standup room already exists), components/widgets/widget- mission.js (one-time intake — this is its daily-recurring sibling) NOTE: Filed verbatim from Commander's ask, S424. Pairs with WO-builder-linktree-base- command (where the accumulated daily record could live/display long-term).", "who": "Commander (design the ritual), Claude (wire the module)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-dev-door-discoverability", "file": "WO-dev-door-discoverability.md", "title": "no discoverable path from the homepage to the actual developer entry point", "what": "Walked 100xbuilder.io live as a cold stranger (S424, browser automation, not code-reading). Confirmed two separate, real problems: 1. The homepage's \"6 doors\" (Join the Crew / Case Builder / 100X Builder / CR Community / OverKORE / The Store — reachable only via ARAYA's \"Show me around\" -> \"The Map,\" since chat covers them by default) contain NO door that says \"Developer,\" \"write code,\" or \"contribute.\" A stranger who wants to build has nothing to tap. 2. The closest-sounding door, \"Join the Crew\" (\"60 seconds — a seat with the builders\"), leads to a GENERAL builder-network signup (builder profile + community + missions board) that is a DIFFERENT system from the actual code-contribution path. It dead-ends at a Forge Passport login wall with no mention of GitHub, packs, or the Developer Cockpit anywhere in that flow. Meanwhile `builder-agreement.html` — the real developer entry point (8 principles, signup form with a Role dropdown defaulting to \"Developer,\" a rail link straight to `dev-board.html`) is fully built and live, but is not linked from the homepage, the 6 doors, or the Join-the-Crew flow anywhere. It only exists for someone who already has the direct URL.", "why": "\"Grand opening\" = a stranger can find their way to real, claimable work with no hand-holding. Today that's false for the code-contribution path specifically — every other door on the site is reachable by browsing; this one isn't reachable at all without being told the URL out loud. This is upstream of every other grand-opening fix: it doesn't matter how good dev-board.html or the pack mechanism get if nothing points a stranger at them. DO: 1. Add a real, findable path to `builder-agreement.html` — either a 7th door on the Map (\"Build the Platform — write code, ship a widget\") or wire ARAYA's chat router to recognize developer intent (\"I want to write code\" / \"how do I contribute\") and route there. Pick whichever is less invasive to the existing 6-door layout — this is additive, not a redesign (Layer Map: land in one layer). 2. Separately, on `builder-agreement.html` itself: replace the current \"Fill this out and you're in. We'll reach out with next steps\" (a manual, unbounded-wait human follow-up) with an immediate handoff — on successful submit, take the developer straight to `dev-board.html` (the page's own right-rail \"Board\" button already does exactly this navigation; just fire it automatically post-submit instead of requiring them to notice and click it). 3. Do NOT touch the \"Join the Crew\" general builder-network flow — it's a real, separate system serving a different audience (non-developer builders/ community). Leave it alone; just stop treating it as if it were the dev path.", "where": "/my/pulse.html (the 6-doors \"Home\" section + ARAYA chat router), /builder-agreement.html (the sign-up form + its post-submit behavior)", "who": "Any Claude window with repo access", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P0", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-dev-one-door-prototype", "file": "WO-dev-one-door-prototype.md", "title": "ONE door — sign in, see the work, claim a WO, ARAYA builds it with you, vault stores it STATUS: open LANE: NOW", "what": "ONE door — sign in, see the work, claim a WO, ARAYA builds it with you, vault stores it STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-devcenter-become-a-person", "file": "WO-devcenter-become-a-person.md", "title": "The identity ladder — anon → person → trusted → builder STATUS: open LANE: NOW", "what": "The entry sequence of the home base — \"how do you become a person.\" An anonymous visitor lands, and a clear ladder takes them from nobody → person (signed in, has an identity + access_level) → trusted → builder. Each rung unlocks more of the surface (which lenses, which rooms, which work they can claim). This is the SAME front-door sequence every business's fractal home base will reuse.", "why": "Commander: \"how do you become a person… understanding who trusts you and why.\" Trust is the product — the character ladder IS the filter (character-ladder-filter). Access must be EARNED, not granted. A stranger and a follower both need one obvious path to go from watching to contributing. Without this rung, the home base is either wide-open (no trust) or walled (no growth).", "where": "100X_DEPLOYMENT — the ONE GATE identity system (access_level int, L0-L7; L0/L1 live per permission-ladder). Wire the front door (WO-devcenter-front-door) to read access_level and gate lenses/rooms/claimable-work by rung. Build Guild ladder files already exist (Build Guild plan).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "The exact rung→unlock map (which access_level unlocks which lens/room/work). Commander sets the trust thresholds — this is why TIER: C / TRANSPORT: hold. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "C", "transport": "hold", "cloud_ready": false }, { "id": "WO-devcenter-reward-loop", "file": "WO-devcenter-reward-loop.md", "title": "Wire done → review → XP actually pays out (+ persist WO claim) STATUS: open LANE: NOW", "what": "Make \"claim → ship → get paid\" REAL. Two broken seams: (1) the done→review→XP payout is COSMETIC — dev_board_tasks.xp is a static field that never pays out on approval, so leveling up doesn't fire. (2) The WO-card claim endpoint (claim-wo.mjs) is a STUB that persists nothing (\"real implementation would write to DB\" — it never does), so the 259 WO cards can't actually be claimed on the web. Fix both so the reward loop closes.", "why": "The one thing Commander cares about as reviewer — \"approve → real reward → level up\" — does not actually happen today. And a home base whose whole premise is \"followers help complete tasks and get rewarded\" is dead if claiming and payout are fake. This is the smallest wire with the biggest payoff: it turns the board from a display into a game with real stakes.", "where": "100X_DEPLOYMENT/netlify/functions/ — tasks-api.mjs + xp-award.mjs + sync-user-xp.mjs (the working SQL claim→XP loop on dev_board_tasks) and claim-wo.mjs (the stub for WO cards). Unify the two claim systems (SQL dev_board_tasks vs the 259 file-driven WO cards via board-feed.mjs) so a claim means the same thing everywhere. ONE XP system (profiles.xp via xp-award.mjs — never an 8th copy).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "XP→access_level promotion thresholds (does hitting an XP bar raise a rung, tying this to WO-devcenter-become-a-person). Confirm one XP amount source (card's xp field) is authoritative. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-file-indexing-ingest", "file": "WO-file-indexing-ingest.md", "title": "EVERY file gets a permanent index number that never changes — find it anywhere it moves STATUS: open LANE: NOW", "what": "EVERY file gets a permanent index number that never changes — find it anywhere it moves STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-gadget-device-store", "file": "WO-gadget-device-store.md", "title": "WO-gadget-device-store — ONE store aggregating maker devices (cyberdecks/radios/gadgets); free test units = the cheat", "what": "One storefront/catalog collecting the maker-device world in one place — cyberdecks, mesh radios, off-grid comms gadgets — curated with honest reviews. Path A: affiliate/curation catalog (day one). Path B: wholesale/resell. Path C: our own devices (WO-cyberdeck-forge output). All three can coexist.", "why": "Commander (S433): \"everybody making devices online — we need to collect them all in one spot and have a store that sells all the kinds of devices. And then they would be giving us devices to test for free, for us to advertise — that's probably the ultimate cheat.\" Review units + tour demos + content engine = the flywheel: devices arrive free → filmed on tour → store sells them → makers send more.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-johnny-store-tenant2", "file": "WO-johnny-store-tenant2.md", "title": "WO-johnny-store-tenant2: Johnny Wicks gets the SECOND store — money lands in HIS account", "what": "Johnny's base command (/u/johnny-wicks, \"We Expose Monsters\" — ALREADY LIVE, linktree-style with a Buy door) becomes a real second store: his products listed, checkout that pays JOHNNY.", "why": "REASON: Commander S467: \"we got to move into making a second store for Johnny Wicks… the base command is going to be like a linktree-style landing, one of the buttons is gonna be a store.\" The store-first doctrine's trio rollout (D→Tiger→Johnny) named him third from the start; Commander's store is live and earning, so Johnny is next. PROBLEM: Johnny's page's Buy door rides the PLATFORM checkout — Commander's Stripe. S463 challenge-bot verdict stands: cloning the store without tenant-parameterization LEAKS Commander's Stripe + phone onto other people's stores. And Johnny-money landing in Commander's account is a bookkeeping/trust mess. UNLOCKS: the store engine becomes multi-tenant for real — every /u/ builder page can grow a store button; the BR pitch (\"sell your products\") becomes literally true for members.", "where": "repo 100X_DEPLOYMENT · base-command.html + u-page.mjs (Buy door, S455) · create-checkout.mjs (tier/price verification path) · hub_profiles row for johnny-wicks · Stripe dashboard → Connect.", "who": "CP3 + Johnny (Stripe Connect onboarding needs him on the phone/screen)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Johnny's availability + his first product decision (title/price). Ask him for both.", "routed": "DEVELOPER", "project": "Store engine (trio rollout D", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-kanban-mvp-status", "file": "WO-kanban-mvp-status.md", "title": "WO-kanban-mvp-status — Add an \"MVP\" status to the Kanban (mark it good-enough-to-ship)", "what": "WO-kanban-mvp-status — Add an \"MVP\" status to the Kanban (mark it good-enough-to-ship)", "why": "Commander: 'we needed like MVP status to do, that actually helped finish the system.' Binary todo/doing/review/done hides the 'it works well enough to ship, polish later' state. An MVP status lets a builder mark a task functionally-complete (MVP) distinct from fully-polished done — so the system reaches usable faster and remaining polish is visible, not lost. DO: 1. Add 'mvp' to VALID_STATUSES in tasks-api.mjs (todo/in_progress/review/mvp/done). 2. Add an MVP column/lane to dev-board.html between Review and Done. 3. Decide XP rule: MVP pays a partial slice; full 'done' pays the rest (ties to WO-mission-elements-partial-xp). 4. Keep the review gate: builder → review; Commander → mvp or done.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-l2-completion-johnny-rachel", "file": "WO-l2-completion-johnny-rachel.md", "title": "close the 3 gaps that make Johnny & Rachel real L2 STATUS: open LANE: NOW", "what": "close the 3 gaps that make Johnny & Rachel real L2 STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-linktree-template-engine", "file": "WO-linktree-template-engine.md", "title": "WO-linktree-template-engine: the welcome page had a baby with Linktree", "what": "Rebuild the /u/ custom-page renderer on the welcome-page card template, with Linktree-grade owner controls: choose which cards show, what size each one is, and links that auto-populate their thumbnails.", "why": "", "where": "", "who": "CP3 FILED: S469 (2026-08-28 evening) — Commander live-grading session, his words captured same-night.", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Builder pages (", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-living-tree-one-view-lenses", "file": "WO-living-tree-one-view-lenses.md", "title": "WO-living-tree-one-view-lenses — One clickable living tree of the whole system; switch lenses (wiring/analytics/money)", "what": "WO-living-tree-one-view-lenses — One clickable living tree of the whole system; switch lenses (wiring/analytics/money)", "why": "Commander: 'one of the cheat codes is making UX for EVERYTHING — because then you have to make it, look at it, and make it adjustable + clickable. We're moving toward an n8n-style living tree we click through to see every phase of every piece of architecture, every code — from the wiring to user analytics to money flow, all from ONE view, clicking through different lenses.' Visualizing every piece is the forcing function that makes it real. The fractal DNA tree (nodes with STATE care-tags) is already the data; this is its visual, clickable face. DO: 1. Render the fractal DNA tree (THE_FRACTAL_STANDARD nodes: OS → views → apps → moves) as a clickable node graph (n8n/flow style) — one view, zoomable. 2. LENSES over the same tree (toggle): WIRING (moves→daemon→data, movemap) · ANALYTICS (usage) · MONEY (revenue flow) · CODE (the mirror) · STATE (done/doing/next) · PHASE. 3. Click a node → its STATE care-tag + which lens data + descend into children. 'UX for everything' — every node is visible + adjustable. 4. ONE source: read the DNA tree + registries + live data; don't fork (anti-fragmentation). Pairs with the code mirror + cyclotron access (a node links its code + its knowledge). 5. This is the top of the cockpit — the map you navigate the whole system from.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-main-chat-discord-simplify", "file": "WO-main-chat-discord-simplify.md", "title": "WO-main-chat-discord-simplify: Remake /main as a normal full-width chat — one room at a time, Discord-shaped", "what": "The signed-in Main Chat view (`/main`) becomes a normal chat room a stranger can use in 5 seconds: pick a room → that room's chat fills the screen. Max 3 columns (nav rail · chat · ONE optional rail, toggleable). Room links actually open the room you clicked.", "why": "REASON: Commander live-tested the card→landing→chat funnel S467 (2026-08-28) and got trapped. Verbatim: \"Extremely busy, no idea how to use it.\" · \"I'm trying to click Builder Revolution and I'm stuck in the Build Guild on this weird view.\" · \"It didn't ask me which one I was trying to sign into and then it just signed me into all three.\" · \"This reminds me of Trello and there's like 5 whole card columns here.\" · \"On Discord there's a full chat that lays out and uses the whole screen — it's not pinched into this little tiny column in the middle.\" · \"Maybe remake this whole damn thing.\" Screenshot receipt: `WORK_AREAS/main-chat-declutter/main-chat-busy-view-s467.png` (caption per Commander: **\"Extremely busy — no idea how to use it.\"**) PROBLEM: This is the landing surface for every business card scanned (/builderrevolution → Join free). A stranger who joins hits: quick-entry gate mid-click → dumped into /main → header says BUILD GUILD (not the room they clicked) → chat is a one-message-wide sliver between CHANNELS, MEMBERS, and a GUILD ABILITIES/CARDS/WORK ORDERS rail. They bounce. The funnel's last mile is broken. UNLOCKS: the card → landing → chat handoff completes; BR room becomes a usable front door; the \"first quest\" pin (join → claim your page → post your build) has somewhere sane to live.", "where": "repo: `C:/Users/dwrek/comms-unity` (github overkillkulture/builder-revolution), branch `main` → Railway auto-deploys ~2-4 min. LIVE: chat.100xbuilder.io files: `src/app/(protected)/main/` (the 5-column view) · `src/app/(protected)/community/[slug]/page.tsx` (the redirect that eats the slug) · `src/components/MenuBar.tsx` (left nav) · Members/WorkOrdersRail components · brandConfig per room in DB `commsunity.\"Community\"` (psycopg2, not REST). tools: node/next locally optional; push-to-main deploys. sign-in needed: repo push (have it).", "who": "developer (CP3 or agent w/ chat repo access)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander's (a)/(b) ratification — that's the only gate; everything else is stageable now.", "routed": "DEVELOPER", "project": "Main Chat (comms-unity", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-mission-elements-partial-xp", "file": "WO-mission-elements-partial-xp.md", "title": "WO-mission-elements-partial-xp — Missions have ELEMENTS; partial fulfillment counts (4/5 done)", "what": "WO-mission-elements-partial-xp — Missions have ELEMENTS; partial fulfillment counts (4/5 done)", "why": "A whole Work Order rarely lands in one clean shot, and binary done/not-done is discouraging + loses partial progress. Commander: 'these tabs want good work orders that turn into bigger things; if a whole WO isn't fulfilled we can at least line up that 4 of the 5 elements are fulfilled.' Decomposing a mission into ELEMENTS makes progress granular, rewards partial work (more fun), and lets a mission GROW into a bigger one when its elements are met. Ties to the 5-organ Living-Loop test (trigger/sensor/actor/gate/writeback) and the DEFINE-WO FIRST-ELEMENT/SPAWN pattern (a spec's elements spawn its build WOs). DO: 1. Add an ELEMENTS list to a mission (a small checklist: e.g. up to 5 named sub-parts, each with its own XP slice). Store as JSON on dev_board_tasks (or a child rows table) — do NOT create a parallel task store. 2. Partial credit: checking an element off awards THAT element's XP via the ONE writer (xp-award.mjs), idempotent per element. The card shows 'X/5 elements · N XP earned so far'. 3. Progress, not binary: a mission at 4/5 shows 80% + which element remains — visible on the board + celebrated in smaller pops. 4. Grow: when all elements are met (or a threshold), SPAWN the bigger follow-on mission (the 'turns into a bigger thing' loop), mirroring the DEFINE-WO SPAWN mechanic. 5. Reuse the review gate: elements a builder self-checks go to 'review'; Commander confirms → element XP pays out (anti-farming, same as whole-WO).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-no-github-contribution-path", "file": "WO-no-github-contribution-path.md", "title": "WO-no-github-contribution-path — Contribute + get ranked WITHOUT a GitHub account", "what": "WO-no-github-contribution-path — Contribute + get ranked WITHOUT a GitHub account", "why": "Real prospective dev: coded a year, uses cloud coding agents, but has NO GitHub. Our repo/PR flow assumes GitHub — that would lock him out. But GitHub is only needed for the self-serve PR path; membership + claim + rank already work without it. Don't require GitHub to be a ranked builder — only to open your own PRs. DO: 1. Confirm sign-in works with Google/email (no GitHub) → profiles row → access_level 1 → can claim + earn XP/rank. (Already true — verify + say so on the invite.) 2. No-GitHub code lane: builder uses their own cloud agent, builds, and SUBMITS work (via ai-cockpit save / vault / a submit form / DM) without touching GitHub. 3. Maintainer LANDS it: a trusted dev/Commander with repo access commits the submitted work and credits the builder — reuse CONTRIBUTING.md 'credit for adopted work' (file header credit + counts toward rank same as a merge). 4. Offer the 5-min 'make a free GitHub' path for those who want self-serve PRs later — optional, not a gate. 5. Invite copy: 'No GitHub? No problem — sign in with email, build with your agent, submit, get credited + ranked. GitHub only when you want the keys yourself.'", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pattern-theory-onboarding-class", "file": "WO-pattern-theory-onboarding-class.md", "title": "turn Pattern Theory into a foundational teaching module so Commander stops re-explaining it one person at a time", "what": "Commander (S424), mid-conversation explaining Pattern Theory to someone new to the platform: \"save this somewhat raw... it seems like that should be some foundational instructions... it needs to go into a work order... instead of me having to tell hundreds of people this, we need some sort of class.\" This is NOT new content. `Pattern Theory: The Activator` already exists as a complete 45,098-word manuscript (`Desktop/1_COMMAND/BOOKS/ PATTERN_THEORY_KDP_V2.docx`, 21 chapters + 3 appendices), already mid-pipeline for hardcover print sale via IngramSpark (see project_pattern-theory-print.md). Commander's own pattern-recognition ability (ACE 18/18, top 1% — see user_pattern-recognition.md) is explicitly documented as the reason the whole platform's architecture (3→7→13→∞) works the way it does — it's not an abstraction, it's how his brain organizes reality, survival-wired from real experience. THIS is the \"game\" framing from the same conversation: builders doing real-world alterations while resistance (what Commander called the NPCs/parasites) tries to stop them — Pattern Theory is the instruction manual for recognizing that resistance for what it is, not evidence you're doing something wrong.", "why": "Two different audiences need Pattern Theory in two different forms — a paying reader (the hardcover book, already in motion, don't touch that pipeline) and a new builder who needs the CORE of it fast, as onboarding, not a 45,000-word read before their first PR. Right now that gap gets filled by Commander explaining it live, one person at a time — doesn't scale, and the live explanations (like the one that triggered this WO) often capture something the polished manuscript doesn't: the raw, immediate version. DO: 1. Capture the raw material NOW, close to verbatim — this session's conversation (and Matthew's exchange within it) is a real instance of Commander teaching Pattern Theory live. Save it close to as-said, not smoothed into corporate copy — that was the explicit ask. 2. Adapt (don't rewrite from scratch) the CORE of the existing manuscript into a short-form teaching module — pulls from PATTERN_THEORY_KDP_V2.docx, condensed to what a brand-new builder needs to understand the \"game\" they're joining. 3. Delivery: this is the natural first candidate for WO-tutorial-course-pipeline (the video tutorial system filed earlier this session) — Pattern Theory as one of the first recorded tutorials, maybe THE first, since it's foundational to everything else being taught. 4. Once it exists as a module: it becomes the thing Commander points new people at instead of re-explaining — the actual DONE= condition.", "where": "Desktop/1_COMMAND/BOOKS/PATTERN_THEORY_KDP_V2.docx (source manuscript, DO NOT edit — the print pipeline reads from this), WO-tutorial-course-pipeline (the delivery mechanism this feeds into)", "who": "Commander (the source knowledge + the raw explanation to capture), Claude/agents (adaptation into teaching format)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-peer-affiliate-selling", "file": "WO-peer-affiliate-selling.md", "title": "builders sell each other's products; ARAYA offers an affiliate fallback for builders with nothing of their own yet", "what": "Commander (S424): once builders have defined products (WO-builder-product-store- definition), everybody should be able to sell each other's products, and ARAYA herself should offer an affiliate link with a cut for anyone who doesn't have their own product to sell yet. IMPORTANT — this is NOT a new system. `project_affiliate-fractal-system.md` confirms recurring commissions + signup attribution are already SHIPPED and live (`referral.mjs`, `referral_partners`/`referral_conversions` tables, `?ref=CODE` capture -> checkout -> webhook). What's missing is the PEER-TO-PEER surface: today it's Commander's product with affiliates, not \"any builder's product, any other builder can affiliate-link it.\"", "why": "Combined with WO-builder-product-store-definition, this is what turns a community of builders into an actual internal economy — everyone has something to sell OR something to earn a cut promoting, no dead ends. DO: 1. RATE RECONCILIATION FIRST: the codebase currently has THREE different commission numbers in play — `commission_rules.default_pct: 25` (the real shipped default), \"30% commission\" (builder-agreement.html's copy), and \"20%\" (Commander's ask this session, specifically for the ARAYA-fallback case). Get Commander to confirm: is 20% a NEW rate specific to the ARAYA-no-product-yet fallback, or should it reconcile with the existing 25%/30%? Don't silently pick one. 2. Extend `referral_partners`/`referral_conversions` so the affiliated PRODUCT can be any builder's Store listing, not just Commander's — the chain-pointer mechanism (`referral_partners.user_id`) already exists for this. 3. ARAYA fallback: if a builder has no product of their own (per WO-builder- product-store-definition), ARAYA offers them a ready affiliate link to something that DOES exist, at the confirmed rate.", "where": "netlify/functions/referral.mjs, project_affiliate-fractal-system.md (read this first — extending shipped infra, not building new) NOTE: Filed verbatim from Commander's ask, S424. Blocked on WO-builder-product-store- definition (nothing to affiliate-link until real offers exist) and the rate reconciliation in DO #1.", "who": "Commander decision (the rate), Claude (wiring)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-phone-answering-cockpit", "file": "WO-phone-answering-cockpit.md", "title": "WO-phone-answering-cockpit — the SaaS phone loop: ding → headset → human closes the sale", "what": "The human-in-the-loop sales cockpit: when a store visitor or caller \"dings in\" (store chat, callback request, or phone line), anyone on duty with a headset gets the alert, answers, and can close the sale. Log every ding: answered-by, outcome, revenue. This is the \"tune the cockpit, then step out of it\" pattern — Commander runs it first, then others earn money answering.", "why": "Commander (S433): \"a store that converts probably has something to do with us being there to answer the phone... anytime somebody dings in it could be to close a sale... at some point this turns into a phone answering service where people make money answering phones and closing sales.\" (Tiger's tax-lien + Aaron's DICOM = future tenants of the same cockpit.) The 10%-human rule: this IS the 10% next to the AI.", "where": "existing rails — ARAYA receptionist + Twilio line + commander-alert SMS + the store pages (offerings consolidation). v1 = wire, don't build: ding → SMS/push to the on-duty person + a simple duty-roster toggle + an outcomes log table.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-reels-section", "file": "WO-reels-section.md", "title": "a native short-video Reels section on our own platform", "what": "Commander (S424): once autonomous social fan-out and the tutorial pipeline are flowing, we'll obviously end up with a real short-form-video output — need a \"Reels\" section for it (native to our own platform, not just posted out to Instagram/TikTok/YouTube Shorts via the fan-out engine).", "why": "The tutorial pipeline (WO-tutorial-course-pipeline) and the social fan-out (SOVEREIGN_SOCIAL_FANOUT_WO.md) both produce short clips as a byproduct (9:16 clips are explicitly already part of the fan-out plan). Right now those clips only exist as things pushed OUT to other platforms — nothing lets a visitor browse them natively, in our own shell, the way they'd browse Reels/ Shorts/TikTok. This is a real content-surfacing gap once the upstream pipelines (tutorials + fan-out) start producing volume. DO: 1. Confirm this is downstream, not urgent yet — depends on WO-tutorial-course- pipeline and the SOVEREIGN_SOCIAL_FANOUT_WO clip pipeline actually producing content first. Building a Reels section with nothing in it is premature. 2. When ready: design as a widget (matches every other content surface on this platform — in-shell, not a new standalone page, per the Layer Map doctrine). 3. Reuse whatever public-media-URL mechanism the fan-out engine already builds (Supabase Storage public bucket, per SOVEREIGN_SOCIAL_FANOUT_WO's own TRAPS section) rather than a second media pipeline.", "where": "New widget (components/widgets/), reuses SOVEREIGN_SOCIAL_FANOUT_WO's media storage mechanism once it exists NOTE: Filed verbatim from Commander's ask, S424. Deliberately marked as downstream/ not-yet-urgent — the upstream content pipelines need to exist first.", "who": "Commander decision (scope), Claude (build once scoped)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-reward-loop-activate", "file": "WO-reward-loop-activate.md", "title": "apply the migrations + merge the ONE clean PR + prove the loop live STATUS: de-risked (S453) — awaiting Commander 2FA LANE: NOW", "what": "apply the migrations + merge the ONE clean PR + prove the loop live STATUS: de-risked (S453) — awaiting Commander 2FA LANE: NOW", "why": "The developer reward loop (claim → ship → approve → get paid → see it) is fully CODED across PRs #1232/#1233/#1234/#1236/#1238/#1239 but NOT yet live. Two migrations must be applied and the stack merged before a builder actually earns visible XP. Until then #1233 payout is fail-closed (inert) and #1239 cap is fail-open (unenforced).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-simplified-toolbars-themes", "file": "WO-simplified-toolbars-themes.md", "title": "WO-simplified-toolbars-themes — Simplify the toolbar; offer a few toolbars + themes", "what": "WO-simplified-toolbars-themes — Simplify the toolbar; offer a few toolbars + themes", "why": "Commander: 'that's why we have toolbars so nothing has to be complicated — simplify the toolbars, maybe a few toolbars and themes.' The toolbar is the thing that makes every page simple; if IT is cluttered, everything feels complicated. Fewer, clearer controls + a small set of theme presets (accent/mode) let a page or a builder pick a clean look without a recode. cr-frame already has accent KNOBS (data-accent) — extend to named theme presets. DO: 1. Audit the current toolbar (cr-frame → cr-forge-header + cr-chrome-v2 dock): cut/hide rarely-used controls; keep the essentials big and obvious (HUD doctrine: NO floating, big text). 2. Define 3-5 THEME presets (e.g. Teal/Dark, Warm, High-Contrast) as cr-frame data-theme values mapping to accent + mode — one attribute swaps the look, no recode. 3. Offer 1-2 toolbar variants (full vs minimal) via a cr-frame knob, so a focused page can run lean. 4. Keep ONE chrome — never add a second bar (HUD_MERGE_BLUEPRINT).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-tier-price-ladder-reconcile", "file": "WO-tier-price-ladder-reconcile.md", "title": "ONE price ladder — kill the $197/$297 vs $297/$697 split STATUS: open LANE: NOW", "what": "ONE price ladder — kill the $197/$297 vs $297/$697 split STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tier2-scout-onboarding", "file": "WO-tier2-scout-onboarding.md", "title": "WO-tier2-scout-onboarding — DM-able \"gather the info\" work orders (onboarding tier 2, no repo)", "what": "WO-tier2-scout-onboarding — DM-able \"gather the info\" work orders (onboarding tier 2, no repo)", "why": "Commander: 'a second level of onboarding where you just tell me what a work order is and I message someone on Instagram — hey, collect all the info to do X.' Not everyone codes or wants repo access. A Scout does pure info-gathering (research, links, contacts, screenshots) that a builder then turns into code. This widens who can contribute from Day 1 and feeds the board. DO: 1. Write a DEAD-SIMPLE scout WO template Commander can paste into a DM: 'MISSION: gather all the info needed to . Send back: <1-2-3 what to collect>. Reply here or at .' 2. Stand up (or reuse) an intake that receives the gathered info and drops it onto the board as a follow-on builder task (reuse drop-inbox / builder-intake, do NOT build a new store). 3. Give Scouts credit/XP too (they earned it) — route through the ONE xp system. 4. 3-5 example scout missions ready to DM (e.g. 'collect all our competitors' onboarding flows + screenshots').", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-trademark-overkor-oa-response", "file": "WO-trademark-overkor-oa-response.md", "title": "OVERKOR TEKNOLOGIES (99417477) — respond to the non-final OA by ~9/2 STATUS: open LANE: NOW", "what": "OVERKOR TEKNOLOGIES (99417477) — respond to the non-final OA by ~9/2 STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P1", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-pattern-theory-revive", "file": "WO-trademark-pattern-theory-revive.md", "title": "PATTERN THEORY (99392373) — petition to revive + OA response, file TODAY STATUS: open LANE: NOW", "what": "PATTERN THEORY (99392373) — petition to revive + OA response, file TODAY STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P0", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-portfolio-master", "file": "WO-trademark-portfolio-master.md", "title": "THE 4 MARKS — one folder, one status file, deadline map, self-file plan STATUS: open LANE: NOW", "what": "THE 4 MARKS — one folder, one status file, deadline map, self-file plan STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P0", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-sou-filings", "file": "WO-trademark-sou-filings.md", "title": "The 8/24 pair — DARRICK PREBLE + OVERKILL KULTURE SOU or EOT, file together STATUS: open LANE: NOW", "what": "The 8/24 pair — DARRICK PREBLE + OVERKILL KULTURE SOU or EOT, file together STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P1", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-tutorial-course-pipeline", "file": "WO-tutorial-course-pipeline.md", "title": "record tutorials in the existing video rooms, turn them into sellable digital products + an onboarding curriculum", "what": "Commander (S424): the video area is about to start making tutorials — teach everything learned over the last two years about coding/building, turn it into digital products for sale, and use it to onboard new people (the \"welders,\" his term for builders). Confirmed live this session: `team-comms.html` already has working video via Jitsi Meet (meet.jit.si) — Standup Room, Dev Room, Case Builders Room, per-channel rooms, \"Summon people\" to ring others in. Recording + product packaging is what's missing, not the video capability itself.", "why": "This is a genuine multi-win: (1) teaching once, recorded, scales infinitely vs. Commander repeating himself live; (2) becomes a real digital product (revenue, matches the existing \"Coach LLM Course Deal\" precedent — co-building LLM courses from recorded material is already proven doctrine, see project_coach-llm-course- deal.md); (3) IS the onboarding curriculum for new builders — pairs directly with WO-developer-screen-set's \"first tasks = your own cockpit\" idea: tutorials teach the exact tools a new builder's first tasks will use. DO: 1. Record: use the existing Jitsi rooms (or direct screen-record) for the first tutorial pass — don't build new recording infra, use what's there. 2. Transcribe + structure: this platform already has a proven local-testbed pattern for recorded-material -> structured course content (see project_law-coach-voice-unit.md, project_coach-llm-course-deal.md) — reuse that pipeline rather than inventing a new one. 3. Package: decide the product shape (Store listing? drip-fed lesson widget? matches \"[SCHOOL] Lesson 1: Your first 72 hours...\" style cards already seen on the live dev-board.html this session — that pattern already exists for at least one other content track). 4. Onboarding hook: new builders get pointed at the relevant tutorial(s) before their first claimed task, not just handed a task cold.", "where": "team-comms.html (recording source — Jitsi rooms), existing course/lesson pipeline precedent (project_law-coach-voice-unit.md, project_coach-llm-course- deal.md — read before building a new pipeline)", "who": "Commander (the teaching), Claude/agents (assembly + product packaging)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-unified-reader-format", "file": "WO-unified-reader-format.md", "title": "WO-unified-reader-format — ONE readable \"reader\" format, spread across the platform", "what": "WO-unified-reader-format — ONE readable \"reader\" format, spread across the platform", "why": "Commander: 'optimize the newsreader format and spread it across the platform so everything is very easy to click and read and see.' Content is presented differently on every page — hard to scan. ONE reader format (big readable type, clear tap targets, consistent cards) applied everywhere makes the whole system feel simple and legible — the opposite of a caveman 10-page slog. Pairs with the ONE chrome (cr-frame) and the HUD doctrine (NO floating, big text). DO: 1. Build components/cr-reader.js: a shared, mobile-first reader block — big readable type, generous tap targets, consistent card/list styling, one accent. 2. Apply it to the content surfaces first: Commander's Log/news, docs, board cards, the export/plan. 3. Do NOT restyle per page — one component, themed by the cr-frame accent knob (see WO-simplified-toolbars-themes). 4. Verify on a phone screen (the primary device) — easy to click, read, see.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-to-claimable-task", "file": "WO-widget-to-claimable-task.md", "title": "build the conversion step from \"graded widget\" to \"claimable dev_board_tasks row\"", "what": "This is the actual blocker to \"onboard developers,\" confirmed live S424: the task board (`dev_board_tasks` in Supabase, served by `netlify/functions/tasks-api.mjs`) has 318 total rows but only 2 tagged `pack:'dev-cockpit'` (the only pack-scoped, claimable-by-a-stranger tasks that exist). Both are `status:'todo'`. One of them — \"Export the links widget as a real pack repo\" — is now STALE: pack-links shipped and is live at github.com/overkillkulture/pack-links. It should be marked done or deleted, not left sitting there as bait for a dev to claim finished work. Meanwhile `DNA/PULSE_WIDGET_REGISTRY.json` has 49 graded widgets with a `checks{}` object per widget describing exactly what's failing and why — that's real, specific, bounded task material sitting unused. Nothing today reads a widget's failing checks and turns them into a `dev_board_tasks` row.", "why": "A dev who signs the Builder Agreement and opens the Developer Cockpit today sees almost nothing to claim. The mechanism to hand them work (packs-as-repos, Developer Cockpit, claim/release, XP) is fully built and proven — it's just empty. Grading widgets (WO-widget-grading-final-9) and triaging D/F ones (WO-widget-df-triage) both produce raw material; this WO is what turns that material into an actual queue a stranger can open and claim from. Without this, \"grand opening\" has a working front door and an empty building behind it. DO: 1. Mark the stale seed task done: `dev_board_tasks` row \"Export the links widget as a real pack repo\" → update status (via tasks-api `?action=update` or direct Supabase update) since it's genuinely finished. Don't leave finished work claimable. 2. Design the conversion: for a given widget id in `PULSE_WIDGET_REGISTRY.json` with failing `checks{}` entries, produce one `dev_board_tasks` INSERT per check (or per logical group of checks) with: - title: short, specific (from the check's own description) - description: what's failing + where + what DONE looks like (borrow the WHY/DONE= pattern from this WO template, condensed to 2-3 sentences — a stranger has none of the surrounding context a WO card assumes) - tier/priority/xp: same fields the S421 seed rows already use as precedent - pack: the `pack_id` from the matching `DNA/PACKS/.json` manifest IF one exists for that widget; if no manifest exists yet, this is also the trigger to write one (a pack manifest is 5 lines of JSON — see DNA/PACKS/README.md) 3. Build this as a script (`scripts/widget-to-tasks.py` or similar — check for a naming precedent in `scripts/` first), not a one-off manual pass — it needs to run again every time a widget is re-graded or a new pack is published. 4. Run it for at least the `links` widget (the one already live as a pack) and any FIX-AS-FIRST-TASK items flagged by WO-widget-df-triage, to prove it end-to-end. 5. Verify in the actual Developer Cockpit UI (not just the API) that a claimable task now shows up for a pack a stranger could realistically pick up.", "where": "DNA/PULSE_WIDGET_REGISTRY.json (source: checks{} per widget), DNA/PACKS/*.json (pack manifests), netlify/functions/tasks-api.mjs (`create`/`update` actions — read the exact field contract before writing inserts), migrations/ dev_board_tasks_add_pack.sql (schema: id/title/description/tier/priority/status/ assignee/xp/pack), components/widgets/widget-cockpit.js (how the cockpit reads/ displays pack-scoped tasks — verify against this, not assumptions)", "who": "Any Claude window or dev with repo + Supabase access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P0", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-voicesummary-conformance", "file": "WO-widget-voicesummary-conformance.md", "title": "~30 widgets fail ArayaShell's own D4-agency conformance check (missing voiceSummary/setupState)", "what": "Live console check (S424, local server run of my/pulse.html) showed ~30 of the widgets registered through the generic V1_WIDGETS delegator (registerV1Widgets(), my/pulse.html) log `[ArayaShell] register(\"\") FAILED conformance: setupState is REQUIRED and must be \"connected\"|\"needs-setup\" · voiceSummary(data)→string is REQUIRED for a voice widget` on every page load — including the new `preview` widget shipped this session, which inherited the same gap by registering through the same delegator. `araya-widget-contract.js` still registers them anyway (degrades gracefully) but flags the failure loudly in console on every single load.", "why": "PLUGIN_CONTRACT.md §10's D4 Agency dimension (\"ARAYA can open it by voice AND summarize it\") is an acceptance criterion nearly every widget's own registry row already marks as `araya_operable: partial — aliases registered, no voiceSummary()` (confirmed directly in `links`/`woboard`/`busfeed`'s freshly-graded rows this session). This is the SAME gap surfacing in two places: the static grading checklist (already known, already logged per-widget) AND a live runtime conformance warning (new information — it fires on literally every page load, for every anonymous visitor, which is a much louder and more frequent signal than a checklist row nobody's looking at). DO: 1. Confirm the exact conformance requirement in `araya-widget-contract.js`'s `validate()` function — what shape `voiceSummary(data)` and `setupState` need to satisfy it. 2. Add a real `voiceSummary(data)` + correct `setupState` to the generic V1_WIDGETS delegator's registration (registerV1Widgets(), my/pulse.html) as a DEFAULT (e.g. `voiceSummary: function(){ return w.title + ' is ready.'; }`, `setupState: 'connected'`) so every widget riding that delegator clears the bar at once — don't hand-fix 30 files individually unless a widget wants a custom summary later. 3. Re-run the local console check: 0 conformance-failure warnings on page load.", "where": "my/pulse.html (registerV1Widgets(), the generic delegator ~line 4640 area), components/araya-widget-contract.js (validate() — read the exact requirement before writing the fix)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-wo-spine-ux", "file": "WO-wo-spine-ux.md", "title": "UX for the work-order spine — a WO IS the gathered kit, all levels navigable STATUS: open LANE: NOW", "what": "A UX for the work-order spine system. A work order should BE everything you'd gather anyway to start the project — and its levels (the R1->R13 rings / zoom levels: one-line → summary → full kit) should be visible and navigable in that UX. Open a WO and you have the whole kit to start: what it is, why, where the files are, what's blocking, the gathered context — presented so a builder (human OR agent) can begin cold. Commander: \"the work order should be all the stuff you'd gather together anyway to start doing the project. All the levels of work orders — do you see them all building in there? We need UX for our work-order spine system.\"", "why": "We've moved fast and now MANAGE lots of work orders — the refocus is WO QUALITY + the COCKPITS to complete them. A WO with no UX is just text; a builder can't feel the levels, can't see what's gathered vs missing, can't start with confidence. The spine UX is what turns \"a pile of cards\" into \"open one, everything's here, go.\" It's the reader half of the Developer Center's Work lens.", "where": "100X_DEPLOYMENT — the Work lens of the Developer Center (WO-devcenter-front-door), reading the board (board-feed.mjs / WORK_ORDERS_BOARD.json) via the canonical parser (parse_wo.py emits the 7-field packet + the ring fields). Render with a canonical pattern (WO-canonical-ux-patterns — likely the DETAIL/profile pattern for one WO + TABLE for the list). Depends on WO quality being real (WO-wo-system-hardening: accurate paths, DONE= command) and context binding (WO-project-context-index).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander confirms the zoom-level model (is it the R1-R13 rings exactly, or a simpler 3-level headline/summary/kit?). Which canonical UX pattern is the base. Ties: WO-devcenter-front-door (the Work lens), WO-canonical-ux-patterns, WO-project-context-index, WO-wo-system-hardening. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "C", "transport": "hold", "cloud_ready": false }, { "id": "WO-youtube-transcription-processor", "file": "WO-youtube-transcription-processor.md", "title": "YouTube transcription processor — chunk startup videos into a blueprint/handbook of patterns + guardrails STATUS: open LANE: NOW", "what": "A YouTube transcription processor. Commander (S424, verbatim): \"stop chasing AI, build this instead... a YouTube transcription processor... as we have people come in we have to make a Northstar direction that we go... we have to build a tax startup and do it with public people so they basically talk for hours on how to build a tech startup and really almost like every damn 3 minutes is a new revelation that needs to be broken down and blueprinted into the direction we're gonna head.\" The processor ingests a video, transcribes it, CHUNKS the ~3-minute revelations, and blueprints each into a handbook: \"somebody organized into different like to-dos, tools, ideas, laws of the universe type deal so that while we're making everything we can guide up against it.\" \"I would imagine that we're going to take a lot of books and put them in here and be trying to make our system with known patterns and guardrails.\"", "why": "Northstar direction is the fix for the ego-of-novelty trap (\"I think in some ways there's an ego element... this way is so special\"). Every ~3 minutes of a good startup video is a revelation that currently evaporates; the processor turns hours of talk into a durable blueprint the whole org (agents AND humans) builds against. The \"laws of the universe\" section = known patterns + guardrails = the same thing THE EASE TEST does for our machine, applied to startup building. Also the concrete first run: the Alex Hormozi warning video Commander references.", "where": "EXTEND the existing pipeline, do NOT build door #2 (blab-capture law, P3). Already built: - `YOUTUBE_DISTILL.py` — atomic concept extraction from captions via OpenRouter (WO-youtube-school, PR #938, commit ccf0ec1c0) - SCHOOL structure: README / INDEX / CURRICULUM / atoms/ (S412) - `AUTO_CHUNKER.py` + `SCHOOL_PROCESSOR.py` + `lesson_to_wo.py` (WO-lesson-to-wo-generator) — LESSON files → WO bones with `source:youtube:` tags - `WO-school-process-queue` precedent: ingest captions → brain atoms → OpenRouter distillation → lesson files (processed Isenberg + Martell videos, LESSON-vJEy3nP2_C8.md, LESSON-Eq8JgI3HmjI.md) Extend YOUTUBE_DISTILL/SCHOOL_PROCESSOR to emit HANDBOOK sections, don't fork the chain.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "which video is the exact \"Hormozi warning\" (URL TBD — Commander to paste or we pick the Alex Hormozi \"stop chasing\" video); whether HANDBOOK.md is a new top-level doc or a SCHOOL section (prefer SCHOOL/ to avoid a 9th registry — blab-capture law); \"tax startup\" phrasing = the business Commander wants publicly built (ARAYA's public launch) — clarify with Commander before building business-specific law entries.", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true } ], "COMMANDER-TODAY": [ { "id": "WO-araya-commander-dashboard-doors", "file": "WO-araya-commander-dashboard-doors.md", "title": "teach ARAYA to voice-open the Commander cockpit dashboards (gated)", "what": "Make ARAYA open the Commander cockpit dashboards by voice FOR COMMANDER ONLY — \"pull up the work order desk,\" \"show me the scorecard,\" \"open agent activity.\" Commander S403 chose voice-via-ARAYA (gated) over cockpit-tap-only. The set (per OUTSIDE_AGENT_READINESS_S397): work-order desk, scorecard+usage, agent activity, notifications, files, email (email already a taught door).", "why": "Commander S403: \"we've got the Commander-7 dashboard widgets — get ARAYA to actually use them.\" The case-builder doors were just proven (S403); this is the second batch. Today ARAYA cannot open any of these by voice except email — they're cockpit tiles, not voice doors.", "where": "Read araya-chat.mjs sections above. Read the S395 tenant console-map path (DNA/build-interface-map.py + the TENANT_MAP_URL loader ~L716-728) — the model for FORK A map-injection. Read WO-araya-widget-doors.md (the case-door teach that just proved out) + memory project_interface-blueprint-s395 (the ONE-state-machine / map doctrine).", "who": "Claude direct (touches the live auth-bearing router — careful, gated) + Commander for the auth test", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "DECISION — FORK A (hand-teach markers vs console-map injection) is Commander's/architecture call, flagged for sign-off before any router edit. UNKNOWN — whether the 5 dashboards should be Commander-ONLY or also member-visible (assume Commander-only until told). Do not fabricate; both flagged. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "ARAYA agency + cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-drive-fixes", "file": "WO-araya-voice-drive-fixes.md", "title": "make ARAYA reliably OPEN cockpit tiles by voice (stop the ability-hijack)", "what": "The commander-dashboard-doors teach + tiles are now fixed (tiles load + register, PR #737). But the LIVE voice test surfaced that ARAYA still doesn't reliably DRIVE the doors by voice. Three concrete issues, in priority order:", "why": "S337 law — \"we built it\" ≠ \"she can drive it.\" The doors are taught and the tiles now load, but the operator still can't reliably open them by voice. Not done until she can.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER", "next": "Commander live voice re-test of item 1's fix (S403c). Items 2 (voice button redesign — design already locked S403b) and 3 (short spoken handles) not started this session — explicitly deferred, item 2 is next if time allows in a future window. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "ARAYA voice + cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-ark-blueprints-radio-consolidation", "file": "WO-ark-blueprints-radio-consolidation.md", "title": "the ~10 ARK blueprints + the parts bins + the radio research become ONE buildable path — \"hand me parts and a blueprint that actually works\"", "what": "One project home where the dormant ARK assets (roughly 10 device blueprints + thousands of dollars of parts in bins, flagged S391, never inventoried) meet the S404 radio market research — and out the other side comes Commander's exact ask: ONE printed blueprint + ONE pulled parts tray for a device that will actually work and actually sell. Not ten maybes — one build, staged like a surgery table.", "why": "Commander S404t: \"I broke my 3D printer and now I'm over here looking at these parts... at this rate I'm never gonna get these out of here. I almost need somebody to hand me parts and a damn blueprint for something that's actually gonna work.\" The blueprints are UNCAPTURED (memory project_ark-electronics-kit: flagged 7/30, zero steps started) — the machine can't stage what it can't see. Capture unlocks everything: triage, the first build card, the kit product, and folding sellables into offerings.", "where": "Work area: `WORK_ORDERS/WORK_AREAS/WO-onboard-physical-builders/` (shared with the radio card — deliberately: one bench project, one staging ground). Siblings: WO-onboard-physical-builders (the crew+SOP) · WO-real-pictures-catalog (the photos) · WO-builder-economy-spine P3 (kits as products).", "who": "Commander/crew captures (phone, 10 min at the bench); Claude consolidates; REFERENCE: the radio RESEARCH_PACKET (4pp, in this card's work area) + Parallel's paid \"Reticulum Network Blueprint\" (the house next door for blueprint+kit products — proof people pay for exactly this).", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "the photographs — the one step only hands at the shop can do. Everything downstream is unblocked the moment they land.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-base-dashboard-quality", "file": "WO-base-dashboard-quality.md", "title": "make the base Pulse cockpit as good as ChatGPT/Claude before we hang magic on it", "what": "A focused quality pass on the BASE Pulse shell/dashboard so its bones — load speed, layout, typography, spacing, empty states, keyboard/mobile feel, the chat surface — hit the bar of a best-in-class AI product (ChatGPT / Claude). NOT new widgets. The frame itself: does opening the cockpit feel as clean and fast as opening Claude? Today it does not, and every widget we hang on it inherits the frame's quality.", "why": "Commander S403: \"we're missing a dashboard that works even as good as any dashboard like ChatGPT or Claude, and THEN we add magical dashboards.\" The clone-proof (WO-widget-forges) showed the belt multiplies a REFERENCE — but you can't belt your way to the first reference; the base shell is the reference every widget clones into. If the frame is mediocre, the whole fleet is mediocre. This is the hand-crafted seed the belt then multiplies (the seed principle: craft one to a high bar, copy it).", "where": "Read `DNA/GOLD_STANDARD_TEMPLATE.md` (the page standard). Read `DNA/WIDGET_FACTORY.md` SHELL LAW (what the shell owns vs the widget). Read `my/pulse.html` shell region (NOT the widget wrappers). Read `components/cr-frame.js`.", "who": "Claude direct (hand-craft — this is the REFERENCE, not a belt job) + Commander eyeball", "status": "open", "claimer": "", "lane_raw": "COMMANDER", "next": "UNKNOWN — the exact numeric target (Lighthouse score? first-paint ms?) is Commander's call; propose one in the audit and confirm. Do not fabricate a target; flag it for sign-off. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ THE WHOLE THING", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-brandon-first-builder-announcement", "file": "WO-brandon-first-builder-announcement.md", "title": "announce the FIRST BUILDER — Commander's video + picture post + Brandon's word", "what": "announce the FIRST BUILDER — Commander's video + picture post + Brandon's word", "why": "Brandon Coleman (GH noblebrendon-cloud) is the FIRST outside builder in platform history to complete a work order: fork → PR → CI green → merged → live → XP. The loop the whole platform exists to prove. Two automated fleet seats died on the same card before him. If this milestone passes unannounced, the proof had no witnesses — the announcement IS the growth engine (\"want to be second?\").", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "", "routed": "COMMANDER", "project": "Builder Revolution", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-cards-shirts-headsets", "file": "WO-cards-shirts-headsets.md", "title": "business cards + T-shirts + headsets — the physical uniform that makes it a real business", "what": "The minimum physical legitimacy kit for the crew: (1) business cards — name, BUILD GUILD / 100xbuilder.io, the 855 number, \"call us\" as the card's whole message; (2) T-shirts — logo front, 100xbuilder.io + phone on the back (a walking dead-end-ends-at-a-call sign); (3) headsets for the call stations (Commander + Aaron first). Ordered this week so they exist before the first real customer calls back.", "why": "Commander S404o: \"the other crazy basic thing we're missing is business cards and some T-shirts. The second people see us with headsets, T-shirts, cards, and we're answering the phone — it kind of becomes a real business.\" Same law as real product photos: trust is bought with PHYSICAL evidence, and this is the cheapest evidence there is. It also works inward — a crew that suits up acts like a business (the uniform effect), which matters the week three people start showing up to a bench.", "where": "Siblings: WO-real-pictures-catalog (the photo lands there) · WO-every-dead-end-calls-us (the shirt/card ARE that law printed on cotton/paper) · TOMORROW_PACKET match sheet (add \"order cards+shirts\" to the bench-day list).", "who": "Commander orders; crew wears; ~$150-300 total; REFERENCE: any real shop crew you've ever trusted — matching shirts + a card in the hand + someone answering the phone IS the trust signal; also the 7 Forges brand kit (colors/logo already exist — no design project needed)", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "crew shirt sizes + Johnny's front-side brand confirmation (his call tomorrow); budget sign-off (Commander, ~$150-300); bench read-aloud of the back copy before ordering. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-case-file-web-view", "file": "WO-case-file-web-view.md", "title": "each case's numbered court record live on the web — docket-style list, downloadable items, coach access, from anywhere", "what": "A per-case web view that looks like what the coach and the docket already look like: one numbered chronological list of every filed item (ours, theirs, orders), each row downloadable, per case, reachable from anywhere. Built as an ARAYA/Pulse WIDGET (widget-or- mode law — never a separate page that kills her session) with its own addressable route per case. The competitor reference Commander named: the coach's Google Drive method + the eCourt docket grid — \"an app already being run by the competitor for web host.\"", "why": "Commander S404g: coach manages cases off Drive; we just staged the criminal case's numbered DRIVE_PACKAGE by hand and Commander sent screenshots. Drive = v1 (coach's rails, live now); this card = v2 — the same structure served by US, so Commander can access any case from anywhere and coach can be given a login instead of a Drive share. This is ALSO the Case Builder product itself: every future case-builder customer needs exactly this screen. The coach's method (his example PNG + his lesson) = the spec AND the training data (coach-LLM deal).", "where": "Widget work → `DNA/WIDGET_FACTORY.md` (the one door). Security → memory project_session-392-opsec-gate-fix + project_permission-ladder. Vision → memory project_case-cockpit-abilities-vision (this IS that interface's records pane).", "who": "Claude (build on the S398 case widgets — do NOT start from scratch); Commander + coach = the two users", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "coach's method lesson (incoming — he offered); the auth choice for coach access (login vs expiring signed links) = Commander/coach call after the lesson. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "Case Builder platform", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-daily-content-engine", "file": "WO-daily-content-engine.md", "title": "WO-daily-content-engine — the daily audio diary + long-form minutes, running by default", "what": "The daily content reps, made frictionless. Two floors, set by Commander (S433): (1) ONE audio diary entry per day — a phone voice memo counts; (2) a set number of long-form video minutes per day (start floor: 20 min raw — screen-record builds count). The SYSTEM parts (claimable): a drop folder where a voice memo auto-transcribes (universal_transcription_service.py exists), lands in the cyclotron, and gets clipped into the podcast pipeline; a scorecard line (daily 5-number scorecard already ships 8am) showing DIARY ✓/✗ and MINUTES so a missed day is visible by 8am the next morning.", "why": "Commander: \"I'm busy hiding from people and I can't do both — I gotta start podcasting, at least an audio diary, and a certain amount of minutes of long-form video each day. I have to start doing this.\" The podcast is the funding engine (house→podcast plan) and the founder-story record. Hiding-compatible: voice-only diary + screen-record builds require zero people. Johnny arriving = second voice in the room when ready.", "where": "Desktop/3_CONNECT/universal_transcription_service.py (exists) · .consciousness scorecard pipeline (Daily Scorecard memory) · TRANSCRIPTS/ drop dir · podcast plan = project_funding-plan-house-to-podcast + van-rig memory.", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "", "routed": "COMMANDER", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-dept-sales-demo-script", "file": "WO-dept-sales-demo-script.md", "title": "Write + test 15-min demo script", "what": "A battle-tested 15-minute demo script with: - 2-min hook (problem agitation) - 5-min product walk (3 key features) - 5-min social proof (case study) - 3-min close (next steps + objection handling) Plus: recorded example, slide deck, printable one-pager leave-behind.", "why": "Current state: Commander improvises every demo. Inconsistent messaging, no delegation possible. A sales department needs REPEATABLE pitches so ARAYA/headless can run discovery calls, not just humans.", "where": "WORK_AREAS/WO-dept-sales-demo-script/ (working) → 100X_DEPLOYMENT/sales/demos/ (final)", "who": "Commander records the gold standard; agent transcribes + structures", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "", "routed": "COMMANDER", "project": "Sales Department (🔴", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-mobile-command-buildout", "file": "WO-mobile-command-buildout.md", "title": "the mobile base — van built out to live/work from, trailer hunt, bus contingency, predetermined stops", "what": "Get one vehicle ready to actually live and operate out of: ① the VAN built out first (power, bed, bench, headset station, radios, Starlink/hotspot — the minimum mobile command) ② hunt an ENCLOSED TRAILER (the rolling shop/inventory) ③ the SCHOOL BUS as the probable forced endgame (scope only, no purchase yet) ④ PREDETERMINED STOPS — a planned route of places/people (allies list: Johnny TN, Bill CA, Andrew, coach WY?) so mobile = a tour, not wandering.", "why": "Commander S404am: \"emergency preparedness follows damn near the same game plan — the one thing not mixed into the plan is we're going mobile, and that bridges the gap to all the rest.\" He's right twice: (a) the PREP MARKET is the same customer as the radio/mesh/ sovereignty products — the mobile unit IS the demo (a van that talks to a mesh with an AI operator = the product, driving around); (b) mobile = the speaking-tour/onboarding vehicle already in memory (speaking-tour plan). The van with matching shirts taking calls from the road is the content engine AND the emergency-preparedness proof.", "where": "Feeds: real-pictures (van build = content) · the prep-market product line · the org blueprint (mechanic seat's first big card).", "who": "Commander + the mechanic seat (see WO-recruit-team-mechanic); REFERENCE: the van-life/ mobile-command build world is FULL of proven layouts (skoolie + van build channels) — pick a reference build, don't design from scratch (house-next-door law).", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "the sell-vs-build call (Commander) · the mechanic (next card) · budget line.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-cockpit-and-voice-debriefs", "file": "WO-onboard-cockpit-and-voice-debriefs.md", "title": "build the ONE onboarding cockpit, then voice-walk real people through every funnel and harvest the debriefs", "what": "Two halves, in order: (A) THE ONBOARDING COCKPIT — one URL a new helper lands on that answers Aaron's three questions: how do I get INTO the system, WHAT is the system, WHERE do I go for my path. Today that page does not exist — the funnels (Case Builder, developer, builder network — the only three actually made, all unproven/wishy-washy) have no cockpit to onboard into. v1 = one page: the four doors + the paths table + \"your first task\" per door, rendered from the board. (B) THE VOICE-DEBRIEF PROTOCOL — call real people (Aaron, Johnny, Rachel, Jay, the Squire) and WALK each one through their funnel and their command-center bucket live, on voice, recording a debrief. Every stumble, every \"where do I click,\" every confusion = a card filed on the board. This is the watched-run doctrine (SOP-from-observation) applied to funnels: the funnel is only proven when a cold human walks it while we listen.", "why": "Commander S404c: Aaron — physically present and willing — \"doesn't even know how to get into the system or what the system is or where,\" and Commander had to say \"it's OK, it's all broken, hold on.\" People are arriving faster than the doors are getting built. The widgets are being fixed in parallel; this card is the ORGANIZING half — get organized for the help that's already here. Debrief Fractal Law applies: every close surveys its operators.", "where": "100X_DEPLOYMENT/onboard.html (new page — Gold Standard template, register in MODULE_REGISTRY, three-systems law). Debrief protocol references feedback_sop-from-observation + feedback_debrief-fractal-law (memory).", "who": "Claude + Commander, first credit-refresh session (Commander S404c: \"tomorrow when the credits refresh we really need to hammer through all that\")", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "none blocking — all inputs exist. Commander schedules the three calls.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-physical-builders", "file": "WO-onboard-physical-builders.md", "title": "onboard Aaron/Johnny/Squire into a physical-builder lane + first radio product run", "what": "Turn the willing in-person crew into a working physical-builder lane: a roles table, a bench work area with the board visible, and a FIRST PRODUCT RUN — pick one radio device that already sells online, get its real parts list, order 10, build #1 while the Squire watches, write the SOP from the watched run, Squire builds #2 from the SOP cold.", "why": "Commander S404: \"I got Aaron here he's willing, Johnny's coming tomorrow, we might get a young Squire kid\" — the people are HERE and there is no lane for them. Thousands of parts on the shelf (Pi Zeros, Pi 5s) are unbuilt revenue (ARK memory). The Builder Revolution umbrella brand needs its first physical proof.", "where": "Desktop/1_COMMAND/ONBOARDING_FOUR_PLANS_S404.md Plan 1 (the full plan) · WO-MASTER-builder-revolution.md (the umbrella) · memory project_ark-electronics-kit (the parts).", "who": "Commander (in person, at the bench) + Aaron Surina + Johnny Wicks + the Squire; Claude preps the research packet", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "Commander confirms which device class (Meshtastic assumed from \"radios/software in the radios\" — if it's a different product, the research packet step re-targets, the process is identical). [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ Builder Revolution (see WO-MASTER-builder-revolution)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-real-pictures-catalog", "file": "WO-real-pictures-catalog.md", "title": "real items, real photos — zero AI-generated product imagery, ever", "what": "A real-photo catalog rule + the first real catalog: every item offered for sale on the platform shows REAL photographs of the REAL item — on the bench, in hand, powered on. NO AI-generated product imagery anywhere in a listing or ad, ever (brand law). First subjects: the first radio units as they're built (unit #1 build tomorrow = the first photo shoot), the ARK kit parts, anything Johnny lists under Exposing Monsters.", "why": "Commander S404n, with Aaron: \"nobody's gonna buy anything off my site until they see real pictures — definitely not putting money in a fake AI-generated ad that looks like a fake product. We have zero agents and zero items for sale with real pictures — we're right at the foundation of ignition with these missing components.\" Trust is the scarce asset; real photos are the cheapest trust we can manufacture, and they're a BYPRODUCT of work already scheduled (the watched build IS the photo op).", "where": "Siblings: WO-onboard-physical-builders (the build being photographed) · THE MONEY page in TOMORROW_PACKET (what's sellable) · WO-builder-economy-spine P3/P4 (what stores will list).", "who": "the bench crew photographs; any agent builds the listings; REFERENCE: any top Etsy/eBay hardware listing (real photos, real hands, real bench — the trust standard to match)", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "which item lists FIRST (radio unit vs an ARK kit vs a Johnny product) — Commander/bench call tomorrow; the card doesn't block on it.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-recruit-team-mechanic", "file": "WO-recruit-team-mechanic.md", "title": "the next seat — an in-person mechanic/engineer for the crew", "what": "One hands-on mechanic/engineer seat filled: a person who owns the physical-systems lane — the van/mobile buildout (WO-mobile-command-buildout), the 3D printer repair, the radio assembly line jigs, the bench infrastructure, eventually the bus. The job CARD (WO form): WHAT they own, first-week tasks (fix the printer · BOM the van · build radio jigs),", "why": "Commander S404am: \"I need to find an engineer... the next guy on our team needs to be a mechanic — recruit an in-person team mechanic.\" Correct read of the gap: the crew has product (Aaron), brand (Johnny), platform (Commander), apprentice (Squire) — nobody owns ATOMS-side infrastructure, and the mobile plan + assembly line both die without it.", "where": "org blueprint OPEN SEATS · siblings: mobile-buildout (their first big card) · onboard-physical-builders (the lane they join).", "who": "Commander recruits (in person, the Squire pattern: found nearby, given a real bench and a real list); REFERENCE: how the Squire got found — proximity + a visible working crew + something real to build. The matching shirts + open garage ARE the recruiting poster.", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "none — recruiting can start the day the shirts arrive.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tiger-signal-forge-handoff", "file": "WO-tiger-signal-forge-handoff.md", "title": "WO-tiger-signal-forge-handoff: Hand Tiger the music-forge codebase so his AI can build on it", "what": "One package Tiger's AI can read cold that says WHAT the music forge is, WHERE every file lives, WHAT'S DONE, WHAT TO BUILD next, and HOW to send work back — clicked/accepted from inside the builder room, not emailed as a blob.", "why": "REASON: Commander S430 (2026-08-10, this session): \"Tiger wants to work on the signal forge... get everything together... package it up to show his AI what we have... make a whole work order... put it out in a place he can get to it... give him a way to get the work order and what we've done and a way to get it back. This is a good test.\" Tiger is the FIRST real outside builder ready to work; he bounced off the terminal+git+Claude-Code onboarding on a Mac (Dec 2025), so the door for him is BROWSER, not CLI (project_trinity-access-button). PROBLEM: We have a live, valuable music system but it's scattered across ~20 files under two different brand names; no cold reader (human or AI) can pick it up and build without a guided manifest. Without a return channel his work never comes back as a WO. UNLOCKS: The first proven round-trip of the Builder Update Exchange — outbound package → outside AI builds → Builder Update comes back and converts to WOs. Proves the browser-only builder lane.", "where": "repo: github.com/overkor-tek/consciousness-revolution (master) — the music assets are all here. files (the handoff manifest — verified live this session, S430): ENGINE: netlify/functions/song-generate-eleven.mjs (PRIMARY — ElevenLabs Music v2, prompt→MP3→Supabase) netlify/functions/song-generate.mjs (alt — Google Lyria 3 Pro) DATA: netlify/functions/songs-api.mjs (catalog read/publish) netlify/functions/schemas/songs-schema.sql (songs table — one source of truth) netlify/functions/schemas/song-orders-schema.sql MONEY: netlify/functions/song-orders.mjs ($47 custom-song order lifecycle) song-order.html · song-order-thanks.html · my/song-orders.html (intake + host queue) UI: song-forge.html (the generator page — LIVE BETA) song.html · music.html (shareable single + community player) WIDGET: components/widgets/widget-music.js (in-OS music dashboard) METHOD: DNA/OVERKORE_MUSIC_SYSTEM.md (the songwriting-craft / Suno method — CAPTURED, NOT yet built into code = the biggest build opportunity) live URLs: song-forge.html (make a song) · song-order.html?host= ($47 order) · music.html (player) tools: none required of Tiger's AI beyond reading the repo. Generation needs ELEVENLABS_API_KEY (server-side, ours — Tiger never handles keys). sign-in needed: Build Guild entry + signed contributor agreement (see the room click-path below).", "who": "Tiger (Brandon McBride, handsonmovers303@gmail.com) + his AI · assembled by CP3", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "- NAMING DECISION (see OPEN-ISSUES) — blocks the card title + which page Tiger lands on. - Guest/comment claim path so Tiger can ACCEPT without a full account (dev-board C4 cliff). - Bucket-2 agreement gate (PR #1108) merged so the signature actually enforces. - A decided file-delivery location (repo browse vs vault zip).", "routed": "COMMANDER", "project": "builder-update-exchange (first real cold-builder handoff)", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false } ], "PUBLIC": [ { "id": "WO-file-sharing", "file": "WO-file-sharing.md", "title": "builders + crew can share files with each other, not just Commander's private vault", "what": "A shared file space for the TEAM/crew zone — the middle of the Galactic Cruiser. Today the vault (just got going, S391 PR #635) is PRIVATE (owner-scoped). This adds the missing \"share a file with each other\" that every collaboration tool has and we don't: a builder attaches a file to a work order / project card / DM and the right people (not the public, not everyone) can see it. The FILES slot of the work-order card, made real for more than one person.", "why": "Commander (S392): \"we don't have anywhere to share files with each other — just barely got the file area going.\" The whole team zone (Johnny, Rachel, incoming builders) can't hand each other a document. Slack/Lark/Notion all have this as table stakes (channel file shares); it's the one Slack component we're most clearly missing on the TEAM side (comms we have via Discord; the private vault we have; team file-share is the gap). Blocks real collaboration on shared work orders.", "where": "repo: github.com/overkor-tek/consciousness-revolution (the 100X deploy repo — all files below live THERE, fetchable by fork; \"home monorepo\" was wrong, fixed S393) files to read first: - netlify/functions/vault-api.mjs + evidence-upload.mjs (the private vault — extend, don't fork) - my/vault.html + doc-vault.html (the UI; S391 fixed uploads) - the work-order card FILES slot (WO-TEMPLATE-painting.md) — files attach BY the never-change ID (WO-file-indexing-ingest) - RLS reference: DNA security notes on case isolation (team-scope is a NEW visibility tier — design the RLS carefully) sign-in needed: Forge Passport (team members); Supabase service key for the function", "who": "developer; Commander confirms who-can-see-whose-files", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "the TEAM-SCOPE definition (what makes two users \"on the same team/project\" — a shared project id? a crew roster table?) is a data-model decision. Confirm before building the RLS. Pairs with WO-file-indexing-ingest (files share by stable ID). || [2026-07-31 S393 STRANGER-TEST: PARTIAL] Fixed the killer defect: WHERE said \"home monorepo\" (a", "routed": "CHEAP-CLOUD-AGENT", "project": "THE PEOPLE (screen 7)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-per-agent-korpak-work-areas", "file": "WO-per-agent-korpak-work-areas.md", "title": "Build role-scoped cockpit work areas for each agent terminal", "what": "Each AGENT terminal (T1/T2/headless workers) gets its own role-scoped cockpit + holding pen for captured to-dos — the same korpak model as human builders, applied to Claude terminals. Replaces dumping to-dos in the desk.", "why": "REASON: S392 Commander directive: \"you are T1 terminal, go into a clean work area\" · PROBLEM: Agent to-dos scatter across FIX_CLIPBOARD, palettes, and session files with no persistent work area · UNLOCKS: Agent self-management, work continuity across sessions, reduced coordination overhead DO: 1. Design agent korpak schema (T1 supervisor, T2 specialist, worker pools) 2. Extend Pulse korpak system to support agent identities 3. Build agent-scoped widgets (claim board, session log, parked chunks) 4. Wire to existing WINDOW_BUS palette system 5. Document agent onboarding to work-area DATA: INPUT: COCKPIT_BLUEPRINT_S392.md, existing korpak implementation · OUTPUT: Agent work-area system · SCHEMA: agent_korpaks table or JSON · INDEX: AGENT_WORK_AREAS.md", "where": "repo: 100X_DEPLOYMENT + home monorepo · files: my/pulse.html, WINDOW_BUS system · tools: node, Supabase", "who": "developer with Pulse widget + korpak system knowledge", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "Full korpak technical spec (read existing implementation)", "routed": "CHEAP-CLOUD-AGENT", "project": "cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-v1-ratchet-opsec-timeout", "file": "WO-v1-ratchet-opsec-timeout.md", "title": "WO-v1-ratchet-opsec-timeout — OPSEC scan in v1-ratchet takes >5 min and times out", "what": "WO-v1-ratchet-opsec-timeout — OPSEC scan in v1-ratchet takes >5 min and times out", "why": "While building WO-builder-green-projects, `v1-ratchet.py --regen` timed out twice: first at 120s, then at 300s, both dying inside `check_opsec()` which calls `opsec-scan.py --json`. The PAGE_LEDGER step completed fine (227 pages), but the OPSEC scan is so slow it blocks the ratchet from finishing. This means builders cannot verify their PRs pass the quality gate before filing, which breaks the \"self-heals\" sprint goal. The opsec scan likely recurses over the entire repo including node_modules or performs expensive regex over large files. DO: 1. Profile `opsec-scan.py` to find the slow path (likely recursive scanning or large-file regex). 2. Add scoped scanning: only check files that changed in the PR, not the entire repo. 3. Add caching: skip files that haven't changed since last scan. 4. Add a fast-mode flag `--quick` for local dev that skips deep entropy analysis. 5. Ensure `v1-ratchet.py` completes in <60s for a typical PR (<20 files changed).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "PUBLIC", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-xp-floors-and-rooms", "file": "WO-xp-floors-and-rooms.md", "title": "WO-xp-floors-and-rooms — Top contributors rise to higher FLOORS; keep building new ROOMS", "what": "WO-xp-floors-and-rooms — Top contributors rise to higher FLOORS; keep building new ROOMS", "why": "The building is the metaphor and the mechanic: as a contributor's XP rises they move UP to higher floors (access_level 2→3→4→5), and each floor has rooms only that floor can enter. Top contributors rise; the higher they go, the more they can do. And we must KEEP MAKING NEW ROOMS — the moment the top floor is 'done', the climb stops. New rooms above = the reason to keep rising. This is the ladder (DNA/DEV_FUNNEL_WALKTHROUGH.md) made spatial + never-finished. DO: 1. Define what each floor (access_level 2/3/4/5) unlocks — the rooms: e.g. F2 Widget Factory publish, F3 multiplayer cockpit seats, F4 dispatch/scope WOs, F5 resell-an-ARAYA-OS. (This defines the currently-blank L2-L4 zone.) 2. Wire the promotion: when profiles.xp crosses a floor threshold, raise profiles.access_level (server-side, via the xp-award path — depends on WO-xp-consolidation). 3. Make arriving on a new floor VISIBLE + rewarding — 'You reached Floor 3. The Squad Room is open.' Show the floor above so the next climb is always in view. 4. DOCTRINE: always keep at least one room above the current top floor under construction, so the ceiling keeps moving. Track it (an OPEN 'next room' card at all times).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false } ], "MACHINE": [ { "id": "WO-araya-walkthrough-coach", "file": "WO-araya-walkthrough-coach.md", "title": "ARAYA coaches live verbal walkthroughs — every caller becomes a Commander-grade bug harvest", "what": "A WALKTHROUGH MODE for ARAYA (voice-first — phone or console voice): the user calls and says \"walk me through my console\" (or she offers it when they sound lost). She then RUNS the protocol Commander does naturally but nobody else will do unprompted: 1. SETUP: \"Open your console on another device — I'll wait. Tell me when you see the top bar with your business name.\" 2. PER-TILE LOOP (driven by the compiled interface map — she iterates the blueprint's widgets in grid order): \"Tap [tile]. Narrate out loud: what do you see? Tap the things inside it. What did you EXPECT to happen? What actually happened? What feels confusing?\" 3. CAPTURE: every friction logged as a DISCRETE bug the moment it's spoken (one at a time — Commander's standing law), tagged {widget_id, expected, actual, device, quote}. Rail: the existing bug/lead capture the receptionist already uses (Johnny's 10-minute-hangup bug arrived exactly this way, unprompted, 7/31) — structured, not a transcript dump. 4. WRAP: she reads back the count (\"we caught 9 — Darrick's team gets these tonight\"), thanks them, and the batch lands in the friction list of WO-tune-tenant-interfaces + the bug board.", "why": "The platform has no scalable way to harvest Commander-grade bug reports. Tenants stumble through consoles silently; friction is invisible. ARAYA walkthrough mode turns every caller into a narrating observer — one 20-minute coached call yields more actionable bugs than weeks of passive monitoring. DO: 1) Locate the call-duration cap in receptionist/twilio config and raise it to 30min for walkthrough-flagged calls. 2) In araya-chat.mjs tenant path, generate a WALKTHROUGH_MODE prompt section by reading DNA/BLUEPRINT/INTERFACES/{tenant}.json (tile list, expected behaviors). 3) Add walkthrough trigger phrases to ElevenLabs PERSONA_OVERRIDES (\"want a guided tour?\" offer when caller sounds lost). 4) Extend the postcall/lead capture rail: add walkthrough=true flag and per-item schema {widget_id, expected, actual, device, quote, timestamp}. 5) Wire wrap report to SMS Commander + write to WO-tune-tenant-interfaces friction list + bug board.", "where": "depends on (build AFTER): the ARAYA map injection (blueprint step 4 — she must know the tiles before she can walk them). Files then: araya-chat.mjs tenant path (walkthrough mode prompt section generated from DNA/BLUEPRINT/INTERFACES/*.json) · ElevenLabs personas (PERSONA_OVERRIDES + tenant agents: add the \"want a guided tour?\" offer + walkthrough script) · capture: the postcall/lead rail with a walkthrough tag + per-item schema · ⚠️ the 10-minute call cap (Johnny's first bug!) must be raised/handled for walkthrough calls or she hangs up mid-harvest — fix that FIRST, it's already on the board.", "who": "Claude builds the persona + capture rail; Johnny + Rachel are the first coached callers; Commander's own narrated walkthroughs = the training reference", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "- REFERENCE: See DNA/WIDGET_FACTORY.md — Widget WOs should reference WIDGET_FACTORY.md", "routed": "CHEAP-CLOUD-AGENT", "project": "araya-agency (PRIMARY) · also touches: tune-tenant-interfaces (WO 0.2) + interface-blueprint (S395) + receptionist product", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-widget-doors", "file": "WO-araya-widget-doors.md", "title": "ARAYA flips screens by voice — every widget door taught, tested, and green on the daily eval", "what": "ARAYA reliably opens/switches any widget in the Pulse shell on request — typed or voice: \"pop out my to-dos,\" \"show me the projects board,\" \"open my leads.\" Screen-flipping = emitting the right [WIDGET:x] marker for every registered widget, including the NEW S392 widgets (projects atlas, ranked to-dos), and staying green on the daily eval harness. PRIORITY (Commander S403): teach the doors in THIS ORDER — (1) the CASE-BUILDER widgets FIRST (caseboard / casetimeline / case — the fleet hardened this weekend), then (2) the Commander-7 dashboard widgets. \"Open the widgets = get ARAYA to actually use them.\" She can't drive the case fleet by voice yet, and that's the highest-value cockpit unlock — it turns the mountain of built widgets into USABLE ones (the S337 law: a widget isn't done until the operator can drive it).", "why": "Commander (S392c): \"Get ARAYA using widgets to where she can flip screens — that should be pretty high on the to-do list.\" It's literally step 1 of the cockpit build order, and the cockpit's whole premise (widgets, never new pages — S337) only works if the operator can drive it. TODAY'S TEST RECEIPT (araya_eval_latest.json 2026-07-30 14:45): 26/28 pass, 0 confabulations, FAILING: `belt_open_tasks` + `wo_file_bug` — the tasks-door scenario is red RIGHT NOW. This WO = fix the red doors + teach the missing ones. WHERE (all verified on origin/master 2026-07-30 — NOTE: the local 100X checkout is 20+ commits behind; grep origin/master, not the working tree): repo: 100X_DEPLOYMENT (worktree + PR per THE MERGE LAW) - netlify/functions/araya-chat.mjs — THE ROUTER: emits [WIDGET:] markers (the flip mechanism) - components/widgets/widget-projects.js + widget-todos.js — the S392 doors (PR #649, live on prod); entry points WidgetProjects.query() / WidgetTodos.top() - my/pulse.html — the ONE shell that hosts/renders the widgets - .consciousness/ARAYA_ROUTING_HARNESS.py — 17+ golden scenarios incl. the TOOLBELT widget-open regression block (WIDGET:leads, WIDGET:links proven S358); daily 7 AM schtask - DNA/ARAYA_UI_MAP.md (before changing any UI) · reference_elevenlabs-agent-config memory (the voice side) sign-in needed: none to build; prod deploy via the gated ratchet", "where": "", "who": "Claude/agent running the S337 teach→tune→watch→fix→record round; Commander drives the real voice test", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "the belt_open_tasks failure diagnosis (first task — read the harness's failure detail in ops_reports) · whether voice STT→router path needs its own scenario class (confirm during TUNE) · who to talk to: Commander (the only real user today); ElevenLabs agent config is in the config-bible memory if the voice layer needs touching. || [2026-08-02 S394 — LEVELED TO L5] Added CLAIMABLE block + DATA section with exact file paths and commands + DO checklist with ordered steps + DONE= checklist with empty boxes to fill on completion. Stranger unit now has everything needed to pick this up and run.", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA agency + cockpit screen glue (blueprint build-order step 1)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-commander-daily-page", "file": "WO-commander-daily-page.md", "title": "the Full Focus daily page — bold ONE THING + Big 3 + appointments + day log, one view, screen and paper", "what": "Unify the EXISTING S364 planner stack into Commander's actual daily page, laid out like the physical Free to Focus planner: THE ONE THING bold at top (usually a system change — \"sell the vehicle\" class), two lesser Big-3 slots under it, today's appointments below, and a DAY LOG pane — the running blog of the day (\"Joe called, wants paint colors\") whose lines get harvested into to-dos at wrap and recycled or deprioritized by the morning rollover.", "why": "Commander (S392c): \"this system tuned into Commander's widgets and cockpit — a practical version of the Free to Focus planner.\" GREP-BEFORE-BUILD RESULT (2026-07-30, receipts read): most of this ALREADY RUNS — do not rebuild: ✅ PLANNER_ROLLOVER.py (schtask 6:45 AM): unfinished→today, one_thing keeps the crown, big3 weight-capped at 3, morning Big-3 SMS via the 855 ✅ PLANNER_WRAP.py (schtask 9 PM): day/week/month/quarter/year wraps — \"Free to Focus ritual cadence\" verbatim; quarterly Big 3 lives in HORIZONS.md ✅ PLANNER_MIRROR.py + a planner widget (rollover header references the widget's big3 cap) The GAPS this WO closes: (a) no first-class DAY-LOG capture surface (today: INBOX.md + texts, harvested only at bootdown), (b) no ONE PAGE uniting Big 3 + appointments + log (calendar widget is separate; MondayPrint prints weekly, not daily), (c) day-log lines don't feed the WO store harvest.", "where": "repo: home monorepo files to read first: - .consciousness/PLANNER_ROLLOVER.py + PLANNER_WRAP.py + PLANNER_MIRROR.py (the engines — READ before touching) - Desktop/1_COMMAND/HORIZONS.md (quarterly Big 3) · the planner/To-Dos/calendar widgets in the Pulse shell - .consciousness/MONDAY_PRINT script + SNAPSHOT facts cache (silent-print rail: Tools/SumatraPDF -print-to-default -silent) - Desktop/1_COMMAND/WORK_ORDER_ARCHITECTURE_S392.md §2 (the harvest flow the log feeds) sign-in needed: Supabase service key (planner tables); none for print", "who": "Claude/agent with planner recon done; Commander supplies planner photos + drives the real-day test", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "- REFERENCE: See ONE_THING + Big-3 + appointments + blank day-log lines (8-10 lines for handwriting) — rate PDF → SumatraPDF -print-to-default -silent # Template: ONE_THING + Big-3 + appointments + blank day-log lines (8-10 lines for handwriting) **ROW:** parent=T11 · kind=page · avenue=agent-fleet · level=L3 · tier=C · verdict=live (blocked: Commander planner photos required) · wave=S462", "routed": "CHEAP-CLOUD-AGENT", "project": "Commander cockpit (screens 1", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-hud-dock-single-source", "file": "WO-hud-dock-single-source.md", "title": "pulse.html should READ the shared HUD_DOORS, not fork its own copy", "what": "`my/pulse.html` defines its own `window.ARAYA_SHELL_NAV` array that fully overrides `components/cr-chrome-v2.js`'s shared `HUD_DOORS`/`hudSkin()` default dock. It has already silently drifted from the shared 5-door set (Report was added there S431, and Comms/Music landed there separately from the shared file S432) — meaning a future shared-dock change again won't reach pulse.html without a second manual edit. Refactor pulse.html to build its NAV array from `HUD_DOORS` (import the id list + any pulse-only extras like 'bug') instead of hand-duplicating every door's icon/label/action.", "why": "Found live S432 (debrief, claude-cp3): changing the shared dock (Comms+Music swap) required a SECOND edit to pulse.html's own array to actually take effect there — the two silently diverged once already (Report) and would again. One source removes the class of bug.", "where": "my/pulse.html (`window.ARAYA_SHELL_NAV`, ~line 51) · components/cr-chrome-v2.js (`HUD_DOORS`, `hudSkin()`, ~line 1510-1572).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "HUD", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-invite-francis-missions", "file": "WO-invite-francis-missions.md", "title": "invite Francis Hornby in (he's dying to be involved) + seed him 2-3 starter missions in the start menu", "what": "Commander S415: \"Francis is dying to be involved... not sure what mission to give him but we should invite him and give him some missions in the start menu at some point.\" Francis Hornby (GateWalker co-builder) emailed Jul 8 2026: \"I would be honoured to be involved.\" Contact: frankhornby6@gmail.com · WhatsApp +490178527565. Invite him + seed 2-3 starter missions on his start menu.", "why": "An eager, capable ally is the cheapest fuel there is — but only if he lands with a clear first mission (not a blank start menu). Seed-before-sell / give a concrete first job.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "people", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-living-tree-build-display", "file": "WO-living-tree-build-display.md", "title": "the manifesto chart as a real-time build display - watch nodes light up as they're done", "what": "Turn the manifesto chart / NODES.json tree into a LIVE build display: each WO-node lights up as it goes open->claimed->done; benchmarks (see WO-fractal-benchmarking-harness) color the nodes by health. People WATCH the tree get built - contributors see their piece land; everyone watches the whole grow.", "why": "The manifesto chart (system-map.html) is a passive poster: contributors cannot see their work land live, and there is no control surface to operate nodes (toggle on/off, wire feeds, adjust parameters). This kills engagement and prevents crowdsourced contributions from feeling real. DO: Modify system-map.html to poll WORK_ORDERS_BOARD.json every 5s, map each WO's status to its corresponding NODES.json node, and render: (a) live status badges (open/claimed/done) on each node, (b) benchmark-based color coding via CSS classes from NODES.json grades, (c) a control panel overlay allowing authorized users to toggle node visibility and wire RSS feeds per node.", "where": "system-map.html (L6 manifesto chart) reads NODES.json - add live status + benchmark coloring + WO-node light-up. Ties to WO-multi-machine-kanban (the board) + WO-chat-doable-crowdsource (contributors).", "who": "CP1 / a widget builder", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "depends on WO-fractal-benchmarking-harness (the node grades) + the live board wiring. || [2026-08-01 S398, Commander] UPGRADE the aim from \"watch it\" -> \"OPERATE it\" (n8n-style). Commander:", "routed": "CHEAP-CLOUD-AGENT", "project": "visibility", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-mission-intake-basecamp", "file": "WO-mission-intake-basecamp.md", "title": "WO-mission-intake-basecamp: Mission intake widget → base camp cockpit (PARKED — named so it can't sprawl)", "what": "The full version of the BR entry: an INTAKE widget that walks a stranger through defining their mission (the SLAY-style 3-step), then hands them a BASE CAMP — a cockpit of their own with a public-facing toggle (private workspace ↔ public builder page). The /claim static form is the v0.", "why": "REASON: Commander S467, verbatim: \"If the widgets worked we would give them a widget to define possible mission — like an intake mission — and it would give them a base camp that was like a cockpit and has a public-facing toggle. But this leads down a rabbit hole that I need a team of people to help code, so that's going to sprawl into Infinity.\" — the card exists to STOP the sprawl: one row, parked, with the entry criteria written down. Same session: slay.ai homework (slaypro.ai, Rebecca Zung's legal-leverage engine) — \"the intake is phenomenal, the layout.\" Its lesson: 3-step intake (Choose → Your info → Checkout), a 3-word promise (Capture → Analyze → Execute), one repeated CTA. That's the SHAPE this widget copies. PROBLEM: today's entry (/claim) is a flat form — no guided iron-out, no cockpit after, no public/private toggle. Works, converts a name into a page, but doesn't yet deliver \"mission ironed out.\" UNLOCKS: the real BR product — mission-as-a-service without an EIN: intake → base camp → things for sale → the book/cards/shirts/song spring off it.", "where": "repo 100X_DEPLOYMENT · claim.html · /u/ engine · WIDGET_FACTORY.md chain · ARAYA cockpit arch (reference_araya-cockpit-architecture: entitlement-packed widget shell — this IS that architecture's \"open AND fill\" use case).", "who": "needs a team per Commander — that's WHY it's parked, not a build order", "status": "open", "claimer": "", "lane_raw": "MACHINE-3", "next": "the team; the widget bar; usage receipts. All named above.", "routed": "COMMANDER", "project": "Builder Revolution", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-node-profile-drilldown", "file": "WO-node-profile-drilldown.md", "title": "clicking any node opens its full profile — what it is, what it was made for, its CTAs, its mechanics log (last/now/next), a screenshot, and its beta level", "what": "Turn the manifesto chart's slide-out panel from a short list into the full NODE PROFILE Commander specced: click a node and see (1) what it is + what it was made for, (2) the calls-to-action on it, (3) its mechanics log = what happened last / what's happening now / future to-dos as work orders with directions + data attached, (4) a picture of the surface (screenshot when it was made), (5) its beta-test level. \"You basically click into it and it shows you everything.\" The node profile is the SAME recursive form as the project profile and the work order — one shape at three zoom levels.", "why": "Data is scattered across MECHANICS_LOG_*.md, FLIGHT_LOG.md, WORK_ORDERS_BOARD.json, and UNKNOWN/NEEDS-RESEARCH analytics source. When a human or agent needs to understand \"what is this node, what does it do, what's its state, what's next,\" they must grep across 4+ files with no single entry point. The map shows 347 nodes but clicking one reveals only a 2-line stub. The problem: context collapse — every node exists in isolation, hiding its purpose, history, and next action. This kills velocity: decisions require manual archaeology instead of one click.", "where": "repo: home monorepo files to read first: - Desktop/1_COMMAND/MANIFESTO_SHAPE.html (the chart + its openPanel() — extend the node model + panel render) - DNA/MECHANICS_LOG_*.md (the per-node history feed — \"what happened to it\") - DNA/BLUEPRINT/NODES.json + system-map.html (the 347-node technical map to reconcile with; don't duplicate) - Desktop/1_COMMAND/WORK_ORDER_STANDARD.md (the \"future to-dos with directions + data\" = the WO form, attached per node) - analytics source: (MISSING — see below) sign-in needed: none to prototype; whatever the analytics feed needs to read traffic", "who": "developer or agent; Commander confirms the profile field list once", "status": "open", "claimer": "", "lane_raw": "MACHINE-2", "next": "the ANALYTICS FEED — \"the traffic of people who clicked through\" — needs a source. Is there a page-analytics store already (check for a Plausible/GA hook or a Supabase page_views table) or is that its own WO? Determine before building section 3's analytics line. The screenshot auto-capture hook does not exist yet — may split into its own small WO.", "routed": "CHEAP-CLOUD-AGENT", "project": "THE MAP (screen 4) leveled up", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-funnel-router", "file": "WO-onboard-funnel-router.md", "title": "the switchboard — every inbound human gets routed to a lane + one action, never a dead end", "what": "A routing layer on the front door: ARAYA (web chat first; 855 line + email-in later) asks ~3 sorting questions and tags every new contact into ONE lane — BUILDER (physical) / DEV (technical) / CASE (needs help) / SUPPORTER (everyone else) — then delivers that lane's day-1 action instead of dumping them into the interface mess.", "why": "Commander S404: \"thousands of people have contacted us trying to help... Commander can't even get anybody in to help because it's just such a mess.\" The four onboarding plans exist (ONBOARDING_FOUR_PLANS_S404.md) but nothing SORTS people into them. The switchboard vision: ARAYA OS as a telephone system — people ding in and get routed.", "where": "Plan 4 in ONBOARDING_FOUR_PLANS_S404.md · WO-araya-v2-pulse-landing-chat (the front door this rides on) · WO-chat-doable-crowdsource (the SUPPORTER/DEV payload) · WO-idea-intake-router (adjacent — that routes IDEAS, this routes PEOPLE; share mechanics if it helps, don't merge).", "who": "any agent comfortable with ARAYA prompts + the contacts API; ~1 session for v1 (web chat only)", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "none blocking v1 — the front-door chat and contacts API are live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "onboarding", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-phone-bug-reporting", "file": "WO-phone-bug-reporting.md", "title": "make the 855 phone agent actually FILE bugs (text + voice) → visible on the bug board", "what": "make the 855 phone agent actually FILE bugs (text + voice) → visible on the bug board", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "confirm WHICH function is the live 855 SMS webhook (araya-phone vs sms-webhook) before editing — a quick test-POST to each tells us; avoid editing the wrong handler. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA phone", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-social-reels-chatroom", "file": "WO-social-reels-chatroom.md", "title": "turn the chat-room area into a social surface — a real FEED + a REELS (short-video) section", "what": "The chat-room area is channel-based text chat today (team-comms.html) plus community Rooms (widget-rooms.js).", "why": "REASON: Commander ask — \"turn the whole chat-room area into a social-media-style surface: a real FEED section + a REELS (short-video) section. Widget or mode, never a new page.\" (this card's source ask, 2026-08-06.) Pairs with the standing [Sovereign Social Fan-Out] project (post-once → broadcast). PROBLEM: the community area is 1:1/room chat only — there is no place to BROADCAST a post to everyone and no short-video format at all. The team/community can talk in a room but cannot scroll a feed or watch reels, so the surface feels like a chat app, not a social platform. UNLOCKS: a social home inside ARAYA OS — a feed to post-once-and-broadcast and a reels lane for short video, the front-end that the Sovereign Social Fan-Out broadcast engine can eventually publish INTO.", "where": "repo: 100X_DEPLOYMENT, master (worktree per LAW #4) files to READ FIRST (do not guess the shape): - team-comms.html — the chat-room area (channels sidebar + message list). A FEED could be a new sidebar section / mode alongside the existing channels; READ how channels render (loadChannels, currentChannel) before adding a mode. - components/widgets/widget-rooms.js — the community Rooms widget (renderCard/renderExpanded, act('join'), backed by rooms-api.mjs, multi-tenant + JWT-scoped). Closest existing pattern for a new social widget: same contract shape (BLUEPRINT, dataFeed/dataSelect, renderCard/renderExpanded, act). - components/widgets/widget-comms.js — the Comms sheet; shows the widget CONTRACT + live-poll + demo/401 gate pattern to CLONE (authHeaders, loadComms, CONTRACT). A feed widget should mirror this shape. - components/widgets/widget-music.js — existing MEDIA widget (audio player). READ for how media is fetched + played; a reels player is the video analog. - components/widgets/widget-files.js — existing file surface; READ to learn whether an upload/storage path already exists that reels could reuse (see MISSING). - DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json — where a new widget's commands get DECLARED (same as the 'rooms'/'comms' entries) so ARAYA can invoke it. tools: node (--check .js), git worktree, netlify (deploy GATED). sign-in: Supabase JWT (same gate as rooms/comms).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "a social-media-style surface layered on that same area — (1) a real FEED section (a broadcast timeline of posts, newest-first, likes/comments) and (2) a REELS section (short vertical videos you swipe). Add both as a widget/mode inside the existing area — NEVER a new page.", "routed": "CHEAP-CLOUD-AGENT", "project": "Sovereign Social Fan-Out", "priority": "P3", "tier": "C", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-supply-lesson-add-production-watchdog-widget-create-a-20260806-052842", "file": "WO-supply-lesson-add-production-watchdog-widget-create-a-20260806-052842.md", "title": "**Add Production Watchdog Widget** — Create a daily automation that queries our", "what": "Implement: **Add Production Watchdog Widget** — Create a daily automation that queries our production DB for key customer events, summarizes them in JSON, and displays a \"Yesterday in Production\" widget in the dashboard with deep-links to actual UI states. This allows the human operator to spot \"that's weird\" anomalies via the \"brain\" interface that automated tests miss.", "why": "Derived from YouTube lesson vJEy3nP2_C8 — strategic implementation of external learnings into our system", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "supply-engine auto-generated", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842", "file": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842.md", "title": "**Implement the 25-Minute Decision Dashboard** — Change the brain/widget notific", "what": "Implement: **Implement the 25-Minute Decision Dashboard** — Change the brain/widget notification system from real-time alerts to batched \"decision windows\" every 25 minutes. Surface only high-stakes decisions (production deploys, architecture changes) during these windows; let low-stakes bug fixes auto-merge to prevent operator burnout while maintaining velocity (target 22-25 PRs/day).", "why": "Derived from YouTube lesson vJEy3nP2_C8 — strategic implementation of external learnings into our system", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "supply-engine auto-generated", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tenant-araya-walkthrough", "file": "WO-tenant-araya-walkthrough.md", "title": "program each tenant's ARAYA to WALK THE USER through their console", "what": "Program the tenant console's ARAYA so it can guide a tenant (Johnny, Rachel, and every future one) through their own console — what the 8 buttons do (Start/Calls/Leads/Comms/Orders/Contacts/ Booking/MyPage), what to test, and the HONEST current state (early version, ARAYA can't drive the widgets yet, some screens are shells). So the AI co-pilots them when Commander isn't on the phone.", "why": "", "where": "tenant console ARAYA at `https://100xbuilder.io/tenant/` + the walkthrough script (use template above or extract from tonight's chat). Pairs with WO-tenant-welcome-message (Start-menu widget) but not blocked by it.", "who": "the tenant-console/ARAYA window (has the console + ARAYA context model)", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "NONE — this work order is L5 CLAIMABLE. Discovery paths are specified in DO step 2. Template script is provided in CLAIMABLE section. If discovery fails (storage location not found), escalate to Commander with search output.", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tune-tenant-interfaces", "file": "WO-tune-tenant-interfaces.md", "title": "take everything we've learned and TUNE the live believers' interfaces — Rachel's and Johnny's, until a real session needs zero Commander hand-holding", "what": "Apply the whole S392-era stack (cr-frame chrome, korpaks, stage-unlock, widget doors, receptionist persona tuning) to the two REAL tenants we already have: **Johnny Wicks** (already testing the receptionist; stage-unlock pilot; tip-line persona bug precedent — it once answered as Preble Pressure Washing) and **Rachel** (Primordial Flow / ArtWorks Land Lab, comped founder). Their interfaces get dialed until they're smooth for THEM — this is the funnel repair executed on believers instead of imagined for strangers.", "why": "Commander (S392c): \"we need to take everything we've learned here and tune the interface for Rachel — we got to tune Johnny's.\" The GTM blueprint's whole premise is seeds-over- strangers; a seeded believer on a messy interface churns exactly like a stranger does, just slower and more politely. These two tuned interfaces also become the template every later tenant clones (the ∞ of the fractal — copy a korpak).", "where": "repo: 100X_DEPLOYMENT (worktree + PR per MERGE LAW) files to read first: **`Desktop/1_COMMAND/ONBOARD_JOHNNY/JOHNNY_WICKS_DNA.md` — THE one spot for Johnny (S395 consolidation: catalog, live surfaces, phone persona, cockpit punch list, all IDs, 19 open items, pointer map — start here, everything else is one hop)** · memory project_johnny-wicks.md + user_rachel-primordialflow.md + project_araya-receptionist-tuning.md · DNA/WIDGET_FACTORY.md (the one door) · the korpak keying mechanism (shipped S381) · johnny-wicks tenant pages + stage-unlock module · Rachel's ArtWorks/Land Lab surfaces sign-in needed: tenant-side test accounts; ElevenLabs config for persona checks", "who": "Claude/agent builds + tunes; Johnny and Rachel verify live (they ARE the receipt); Commander introduces the session", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "Rachel's current surface inventory (what she actually uses today — pull from her memory file + ask her) · MORE of Johnny's friction in his words (first item captured above) · scheduling both verification sessions (Commander intro text, one line each). NOTE: Step 3's test call doubles as the outstanding receipt for the S391 PERSONA_OVERRIDES pressure-washing fix (PR #639) — deployed, never call-verified. One call closes both.", "routed": "CHEAP-CLOUD-AGENT", "project": "tenant-experience (PRIMARY) · also touches: first-believers (GTM Phase 0) + AI-receptionist + korpaks + stage-unlock — the many-to-many law's first real card (WORK_ORDER_STANDARD §5)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-widget-json-role-filtering", "file": "WO-widget-json-role-filtering.md", "title": "gate the todos/projects/board widget JSON by role — stop shipping the whole store to every viewer", "what": "`widget-todos.js`, `widget-projects.js`, and `widget-workdesk.js` all fetch ONE generated JSON (`PROJECT_REGISTRY.json` / `WORK_ORDERS_BOARD.json`) with no server-side role filter — a DEVELOPER-tier viewer currently sees the exact same lanes/cards/seats as COMMANDER. This WO makes the generators (or a thin serving layer) filter by the signed-in role before the JSON leaves the server, not just hide-in-the-UI (client-side hiding is not access control).", "why": "`widget-workdesk.js`'s own header comment names this explicitly: \"no korpak-based lane filtering yet: a DEVELOPER seat sees every lane the same as COMMANDER today, because none of the shipped widgets in this fleet gate their JSON server-side yet (todos/projects/board are the same).\" That comment has claimed since S392/S394 that this was \"filed as a follow-up WO, not silently shipped as done\" — checked S395: no such WO existed. This WO makes that claim true. Commander also named the Team/Commander view toggle on the board widget as a stand-in (\"YES filter by role, and the filter IS the Commander-vs-team UX\" — WO-board-ux-widget) but that toggle is currently a plain UI switch anyone can click, not a role check — it doesn't close this gap, it just proved the UX shape.", "where": "repo: 100X_DEPLOYMENT (worktree + PR + same-session merge, MERGE LAW) files to read first: `components/cr-page-gate.js` (the live role source — reuse it, don't invent a second identity check) · `DNA/PROJECTS/build_project_registry_json.py` + `DNA/generate_work_orders_board.py` (the two generators that would need a role param) · `DNA/MECHANICS_LOG_IDENTITY.md` (once WO-publish-role-ladder-mapping lands, the canonical role vocabulary to filter against) · the three widget files' HONEST GAPS comments sign-in needed: a signed-in DEVELOPER-tier test account to prove the filter actually hides something (not just COMMANDER, who should see everything)", "who": "unclaimed — any agent with `components/cr-page-gate.js` + the three widget generators open", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "the exact role→visible-lane mapping (which lanes/cards a DEVELOPER should NOT see) — Commander decision, not a Claude default; whether role changes need to take effect without a rebuild (picks HOW step 2's option a vs b).", "routed": "CHEAP-CLOUD-AGENT", "project": "identity", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-widget-out-agent-activity", "file": "WO-widget-out-agent-activity.md", "title": "agent-activity — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: open-event: click a feed row -> deep-link to that WO on the board (route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-agent-activity.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"agent-activity\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: route-out: /my/pulse.html?open=workdesk&wo= DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (route-out: /my/pulse.html?open=workdesk&wo=). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-agent-activity.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — none — pure client route-out). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-booking", "file": "WO-widget-out-booking.md", "title": "booking — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: confirm + cancel a booking (and add-to-calendar route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-booking.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"booking\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/booking (action=confirm|cancel) DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/booking (action=confirm|cancel)). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-booking.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — booking fn (verify write actions exist)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-files", "file": "WO-widget-out-files.md", "title": "files — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: send-file (drop a file to a machine) + open-file (route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-files.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"files\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/file-transfer + open link DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/file-transfer + open link). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-files.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — file-transfer fn (verify exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-orders", "file": "WO-widget-out-orders.md", "title": "orders — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: mark-fulfilled + open-order (route-out to the order detail). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-orders.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"orders\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/orders (action=fulfill) DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/orders (action=fulfill)). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-orders.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — orders fn (verify write action exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-revenue", "file": "WO-widget-out-revenue.md", "title": "revenue — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: open-wallet-actions: route-out to cash-out/transfer (a readout earns ability-first via route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-revenue.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"revenue\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: route-out: open wallet action surface DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (route-out: open wallet action surface). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-revenue.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — wallet action surface (verify target exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false } ], "UNLANED": [ { "id": "WO-S439-devsuite-wireup-batch", "file": "WO-S439-devsuite-wireup-batch.md", "title": "WO BATCH — Dev-Suite Wire-Up + 4-Week Plan (S439, 2026-08-14)", "what": "three inconsistent claim gates coexist (tasks-api=sign-in→+CLA; todo-claims-api=L5+ role; claim-wo=stub). Consolidate to ONE claim contract. WHERE: the 3 functions. DONE: one documented claim gate.", "why": "recurring leak; SENS wall is a net, not a fix. WHERE: the dev-news.json generator (not in obvious *.py/*.mjs — trace the Commander's-Log feed writer). DONE: generated dev-news.json never contains case numbers.", "where": "netlify/functions/claim-wo.mjs. DONE: no path lies about success.", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-S466-interface-dna-followups", "file": "WO-S466-interface-dna-followups.md", "title": "WO BATCH — S466 Interface-DNA Tracing + Vault Follow-ups (2026-08-28)", "what": "Show a doc's version chain using the `metadata.revision_of` links already written by save-v2. A \"versions\" affordance on a doc that has revisions.", "why": "save-v2 records the chain but nothing displays it yet.", "where": "`commander-vault-feed.mjs` (a revisions query) · widget-canvas doc view.", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-agent-readable-contract-floor", "file": "WO-agent-readable-contract-floor.md", "title": "WO-agent-readable-contract-floor — a widget claiming agent.readable=true must return live capabilities", "what": "WO-agent-readable-contract-floor — a widget claiming agent.readable=true must return live capabilities", "why": "Wave-3 batch-3 critic — NEW root: declared-vs-executable AGENT-READABILITY gap. Multiple widgets advertise agent.readable=true + voiceIds/aliases, but runtime introspection returns dead/capability-less data OR the execution path can't fulfill the claim (woboard declares agent-readability but returns a phantom claim-wo; page is fully driveable but ABSENT from WIDGET_COMMANDS.json so agents under-report it). This is distinct from WO-widget-contract-fleet-sweep (missing methods) — here the METHOD exists but LIES. DIRECTLY blocks the ARAYA curriculum (project_araya-curriculum): if a widget claims agent-readable but returns nothing, ARAYA's map teaches a capability that doesn't execute. DO: define the floor — a widget declaring agent.readable=true must (1) appear in WIDGET_COMMANDS.json, (2) return live, executable capability data on introspection (not a stub), (3) have its declared commands actually reachable via araya-chat [WIDGET:id]/command path. Sweep; make each claim true or drop the claim.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-ar-receipt-floor", "file": "WO-ar-receipt-floor.md", "title": "WO-ar-receipt-floor — every widget server-mutation must emit a visible receipt (nothing fails silently)", "what": "WO-ar-receipt-floor — every widget server-mutation must emit a visible receipt (nothing fails silently)", "why": "Wave-3 batch-2 completeness critic found a NEW uncarded cross-widget root: Action→Reaction NO-RECEIPT silent mutation. Server writes and money actions fire with no user-visible reaction/receipt across ≥3 widgets (comms markContacted/reopen, earn mission completions, calls save). This is the \"nothing fails silently\" doctrine violated at cluster scale — distinct from the telemetry clobber (that's the gauge; this is the user seeing nothing when they act). Batch-1's calls silent-death was the first instance; the critic confirms it's a pattern. DO: define the AR-receipt floor for a widget mutation (optimistic UI + confirmed/failed toast tied to the RESPONSE BODY, not just HTTP status — see the calls fix PR #1217 pattern). Sweep each widget's mutations; every one emits a visible confirm on success and a loud visible error on failure. Consider a shared helper.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-action-record-widget", "file": "WO-araya-action-record-widget.md", "title": "WO — Action Record widget: a visible receipt for every action ARAYA claims to take", "what": "WO — Action Record widget: a visible receipt for every action ARAYA claims to take", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-bug-system-cleanup", "file": "WO-araya-bug-system-cleanup.md", "title": "WO-araya-bug-system-cleanup — Fix stale bug-repo pointer + tighten ARAYA intake gate", "what": "WO-araya-bug-system-cleanup — Fix stale bug-repo pointer + tighten ARAYA intake gate", "why": "S446 traced ARAYA's ElevenLabs/voice bugs — they land in Supabase `araya_bugs` (128 rows, live) + GitHub `overkor-tek/consciousness-bugs`, NOT the chat's bugReport table. The repo MOVED (S411) but CLAUDE.md standing orders still say `overkillkulture/consciousness-bugs` → looking there shows nothing (\"where are ARAYA's bugs?\"). Also the intake gate `isNotABug()` blocks leaked prompts but low-signal fragments still slip through (#123 \"Yeah, go ahead and do that\", #119 \"Not working\"). DO: 1. Grep CLAUDE.md + .consciousness + scripts for `overkillkulture/consciousness-bugs`; repoint to `overkor-tek/consciousness-bugs`. 2. In `100X_DEPLOYMENT/netlify/functions/araya-tool-bugs.mjs` isNotABug(): reject bare acknowledgements / too-few-content-words / no problem-signal (add a min \"signal words\" heuristic beyond the current length check). 3. Optional: a weekly ARAYA-bug triage (dedupe, close low-signal) — its own loop.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-canned-reply-regression", "file": "WO-araya-canned-reply-regression.md", "title": "WO — Stop ARAYA's ability router from eating ordinary questions into canned \"Commander will see it\" acks", "what": "WO — Stop ARAYA's ability router from eating ordinary questions into canned \"Commander will see it\" acks", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-case-tool-live-hearings", "file": "WO-araya-case-tool-live-hearings.md", "title": "WO — ARAYA case tool returns stale hardcoded hearings → point it at a live source", "what": "WO — ARAYA case tool returns stale hardcoded hearings → point it at a live source", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-clip-shorts-extractor", "file": "WO-araya-clip-shorts-extractor.md", "title": "WO-araya-clip-shorts-extractor — Long-form video → AI-cut 9:16 shorts + captions + music", "what": "WO-araya-clip-shorts-extractor — Long-form video → AI-cut 9:16 shorts + captions + music", "why": "Johnny (S441 debrief) + the podcast plan both need it — drop a long-form video in, get postable shorts out. Reuses the transcription ability (WO-araya-transcribe-ability) for the transcript that drives clip selection. This is the media-production agent he asked for. DO: - Input: a long-form video (or one already transcribed). Use the transcript + simple heuristics (or an LLM pass) to pick 3-8 highlight moments. - Cut 9:16 vertical clips with ffmpeg; burn captions from the transcript; optional auto-music bed (reuse the music-gen pipeline). - Output to the user's Vault, review-then-post; hook the existing social fan-out for one-button posting. - No silent caps: show how many clips, let the user pick/trim.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-command-vs-conversation-intent", "file": "WO-araya-command-vs-conversation-intent.md", "title": "WO-araya-command-vs-conversation-intent: know when to ACT vs when to just TALK ABOUT it", "what": "WO-araya-command-vs-conversation-intent: know when to ACT vs when to just TALK ABOUT it", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-curriculum-from-registry", "file": "WO-araya-curriculum-from-registry.md", "title": "WO-araya-curriculum-from-registry — teach ARAYA everything from ONE generated map (no parallel doc)", "what": "WO-araya-curriculum-from-registry — teach ARAYA everything from ONE generated map (no parallel doc)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-araya-email-takeover", "file": "WO-araya-email-takeover.md", "title": "WO — ARAYA email takeover: email-to-vault door → filters/forwarding → the share-sheet door", "what": "WO — ARAYA email takeover: email-to-vault door → filters/forwarding → the share-sheet door", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-energy-createaccount-id-fracture", "file": "WO-araya-energy-createaccount-id-fracture.md", "title": "WO-araya-energy-createaccount-id-fracture — createAccount mints a random id, not the caller's canonical id", "what": "WO-araya-energy-createaccount-id-fracture — createAccount mints a random id, not the caller's canonical id", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-fake-action-confirmation", "file": "WO-araya-fake-action-confirmation.md", "title": "WO — ARAYA claims \"bug report filed\" without gathering the bug, and confirms success even when the write failed", "what": "WO — ARAYA claims \"bug report filed\" without gathering the bug, and confirms success even when the write failed", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-file-lifecycle-template", "file": "WO-araya-file-lifecycle-template.md", "title": "WO — ARAYA FILE LIFECYCLE = THE ABILITY TEMPLATE (give · share · retrieve)", "what": "WO — ARAYA FILE LIFECYCLE = THE ABILITY TEMPLATE (give · share · retrieve)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-file-open-ability", "file": "WO-araya-file-open-ability.md", "title": "WO — ARAYA ability #1: pull up a file, SHOW it, put it back", "what": "WO — ARAYA ability #1: pull up a file, SHOW it, put it back", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-infographics-agent", "file": "WO-araya-infographics-agent.md", "title": "WO-araya-infographics-agent — On-demand educational infographic cards", "what": "WO-araya-infographics-agent — On-demand educational infographic cards", "why": "Johnny (S441 debrief) makes many educational infographic cards for Facebook by hand — \"an easier way for people to learn.\" Automate: topic/points in → a clean branded image card out. DO: - Input: a topic + a few bullet points (or a paragraph the agent summarizes into points). - Render a branded card (reuse the brand-kit / dataviz standard) — title, 3-7 points, clean layout, light + dark. Export PNG to the user's Vault. - Optional: batch a series from a longer doc; route to social fan-out.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-lever-not-autotrigger", "file": "WO-araya-lever-not-autotrigger.md", "title": "ARAYA DECIDES to open a widget (tool-use) — kill the keyword auto-override STATUS: open LANE: NEXT-BIG", "what": "ARAYA DECIDES to open a widget (tool-use) — kill the keyword auto-override STATUS: open LANE: NEXT-BIG", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT-BIG", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-memory-empty-read-anomaly", "file": "WO-araya-memory-empty-read-anomaly.md", "title": "WO-araya-memory-empty-read-anomaly — deployed araya-memory get_context returns empty for real account rows", "what": "WO-araya-memory-empty-read-anomaly — deployed araya-memory get_context returns empty for real account rows", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-memory-read-auth", "file": "WO-araya-memory-read-auth.md", "title": "WO-araya-memory-read-auth — gate unauthenticated READS of araya-memory", "what": "WO-araya-memory-read-auth — gate unauthenticated READS of araya-memory", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-offline-mode", "file": "WO-araya-offline-mode.md", "title": "WO-araya-offline-mode — ARAYA runs with no internet", "what": "WO-araya-offline-mode — ARAYA runs with no internet", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-os-install-the-system", "file": "WO-araya-os-install-the-system.md", "title": "WO-araya-os-install-the-system: break the system into widgets → the book → install it AS an OS, ON ARAYA, from the phone", "what": "WO-araya-os-install-the-system: break the system into widgets → the book → install it AS an OS, ON ARAYA, from the phone", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-own-voice-downloadable", "file": "WO-araya-own-voice-downloadable.md", "title": "WO-araya-own-voice-downloadable — ARAYA carries HER OWN neural voice everywhere (kill the stock device fallback)", "what": "WO-araya-own-voice-downloadable — ARAYA carries HER OWN neural voice everywhere (kill the stock device fallback)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-per-user-scoped-token", "file": "WO-araya-per-user-scoped-token.md", "title": "WO-araya-per-user-scoped-token — Per-user scoped API tokens (builders reach ONLY their own data)", "what": "WO-araya-per-user-scoped-token — Per-user scoped API tokens (builders reach ONLY their own data)", "why": "To let Johnny / Odin / any builder use ARAYA (web OR their own Claude Code MCP) WITHOUT the admin key (CR_83d0…, full access to EVERYONE). S441: wiring Johnny's Claude Code was BLOCKED because the only credential is that admin key — handing a new person full-system access breaks no-single-capture. Per-user scoped tokens = the safe unlock for the whole builder-cockpit vision. DO: - Mint per-user tokens (tied to profile/user_id) scoping list/create/update/delete to rows where assignee/owner == that user (+ their allowed avenues/scope). - MCP server accepts `ARAYA_USER_KEY` (not admin); enforce scope SERVER-SIDE (never trust client). - Revocable, logged, no PII in the token. - Deliver Johnny a scoped token + the MCP snippet so \"show my tasks\" works on his box safely.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-personality-restore", "file": "WO-araya-personality-restore.md", "title": "WO-araya-personality-restore: bring her character back WITHOUT the fake-action hallucination", "what": "WO-araya-personality-restore: bring her character back WITHOUT the fake-action hallucination", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-premium-voice-and-puppeteer", "file": "WO-araya-premium-voice-and-puppeteer.md", "title": "WO-araya-premium-voice-and-puppeteer: premium voice on the cockpit + landing-page talking-chat + puppet strings", "what": "WO-araya-premium-voice-and-puppeteer: premium voice on the cockpit + landing-page talking-chat + puppet strings", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-premium-voice-tablet", "file": "WO-araya-premium-voice-tablet.md", "title": "WO-araya-premium-voice-tablet: get the good (neural) voice onto tablet/mobile — stock voice is terrible", "what": "WO-araya-premium-voice-tablet: get the good (neural) voice onto tablet/mobile — stock voice is terrible", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-presenter-artifact-pane", "file": "WO-araya-presenter-artifact-pane.md", "title": "WO — ARAYA Presenter: the artifact pane (Claude & ARAYA \"show their work\")", "what": "WO — ARAYA Presenter: the artifact pane (Claude & ARAYA \"show their work\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-product-dna", "file": "WO-araya-product-dna.md", "title": "WO-araya-product-dna — Product DNA record: ARAYA L1 (the template for every product; unlocks L2/L3)", "what": "Every product we SELL gets ONE complete \"Product DNA\" record — the single place holding everything a buyer AND a builder needs. Define the repeatable 6-part shape, fill it for **ARAYA L1** (the thing we're selling right now), and stub **L2 / L3** so the ladder is definable. Includes the on-page ARAYA UX redesign (research how others embed/lease AI; replace the big-A intercom orb with something simpler that works on mobile).", "why": "We're selling an object; the object needs a blueprint. Today it's scattered — listing in products.json, wiring in MECHANICS_LOG_VOICE, abilities in COMPONENT_REGISTRY, and NO customer explanation / onboarding / L2 / L3. One Product DNA record per product = (a) the buyer-trust asset, (b) the clone template for the platform, (c) the thing that makes L2/L3 definable (same DNA + more abilities).", "where": "EXTEND existing homes (no new store, no-8th-copy): `DNA/MECHANICS_LOG_VOICE.md` (wiring) · `store/products.json` (listing) · `DNA/COMPONENT_REGISTRY.json` → `intercom-orb` (UX object) · a per-product DNA record that INDEXES these + adds the missing customer-explanation + onboarding.", "who": "araya lane.", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-signout-loop-forge-passport", "file": "WO-araya-signout-loop-forge-passport.md", "title": "WO-araya-signout-loop-forge-passport: sign-out immediately auto-signs back in (can't switch accounts)", "what": "WO-araya-signout-loop-forge-passport: sign-out immediately auto-signs back in (can't switch accounts)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-transcribe-ability", "file": "WO-araya-transcribe-ability.md", "title": "WO-araya-transcribe-ability — ARAYAOS \"Transcribe\" ability: add-from-store widget that turns any audio/video into text", "what": "WO-araya-transcribe-ability — ARAYAOS \"Transcribe\" ability: add-from-store widget that turns any audio/video into text", "why": "Commander's ask, S441 — \"this would be a great ability for ARAYAOS: go to the store, see a transcribing app, add it to your main widget list, and it transcribes a video or audio recording (mp4/m4a/mp3/wav).\" This is the intake on-ramp for the whole WO Router: a recording → text → tasks/ vault. FEASIBILITY PROVEN THIS SESSION (S441): a 26MB / ~13-min `.m4a` was transcribed on CP3 with local `faster-whisper` (small.en) after an `ffmpeg` convert to 16kHz mono wav; and CP2's GPU Whisper endpoint is live (`http://100.119.89.85:8880/stt`, cuda). So the backend is not a research question — it's a wiring job. DO: - STORE LISTING: add \"Transcribe\" to the ARAYAOS store/marketplace with a real screenshot + one-line description (\"Drop in any audio or video — get the text back, attached to your Vault/Notes\"). - ADD-TO-WIDGETS: reuse the existing add-a-widget / pack-bind flow so it lands in the user's main widget list (owner-scoped; no PII). Collapses when not in use like other widgets. - THE WIDGET: accepts a file (m4a/mp3/mp4/mov/wav) OR a recording already in the Vault. On submit: ffmpeg → 16kHz mono wav → transcribe. Show a visible \"transcribing…\" state (the she's-thinking rule). - BACKEND (pick + wire, don't rebuild): primary = CP2 GPU Whisper `POST :8880/stt` (fast); fallback = local `faster-whisper` (small.en, int8) for offline. Same code path as the S441 proof script (`Downloads/transcribe_voice.py`) — promote that into a real endpoint. - OUTPUT: write the transcript to the user's Vault/Notes (reuse the notes-feed backend), tagged `transcript`, with a \"→ turn into tasks\" button that tees up WO rows (feeds the WO Router). - LIMITS: show duration/size cap + cost note; long files run async with a \"ready\" ping (no silent cap).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-button-and-widget-puppet-strings", "file": "WO-araya-voice-button-and-widget-puppet-strings.md", "title": "WO — ARAYA voice button on the dashboard + voice-controls-the-widgets (\"puppet strings\")", "what": "WO — ARAYA voice button on the dashboard + voice-controls-the-widgets (\"puppet strings\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-compat-red-tape", "file": "WO-araya-voice-compat-red-tape.md", "title": "WO-araya-voice-compat-red-tape: unwrap the voice-length limiting + the failing auto widget-TTS layer", "what": "WO-araya-voice-compat-red-tape: unwrap the voice-length limiting + the failing auto widget-TTS layer", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-notification-arbitration", "file": "WO-araya-voice-notification-arbitration.md", "title": "WO — One audio arbiter: ARAYA never talks over notifications (turn-taking)", "what": "WO — One audio arbiter: ARAYA never talks over notifications (turn-taking)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-streaming-stt", "file": "WO-araya-voice-streaming-stt.md", "title": "WO — Cut ARAYA voice turn-start lag: streaming/partial-commit STT", "what": "WO — Cut ARAYA voice turn-start lag: streaming/partial-commit STT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-streaming-tts", "file": "WO-araya-voice-streaming-tts.md", "title": "WO — Stream ARAYA's answer + TTS per-sentence (first audio in ~1-2s, not ~11s)", "what": "WO — Stream ARAYA's answer + TTS per-sentence (first audio in ~1-2s, not ~11s)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-aries-dissect", "file": "WO-aries-dissect.md", "title": "dissect Johnny's \"IRON ARIES\" software (ARIES_CORE v0.1) STATUS: open LANE: NEXT", "what": "dissect Johnny's \"IRON ARIES\" software (ARIES_CORE v0.1) STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-attach-share-vault-roundtrip", "file": "WO-attach-share-vault-roundtrip.md", "title": "WO-attach-share-vault-roundtrip — Make the attach→vault loop actually close (the \"does it work\" bug)", "what": "WO-attach-share-vault-roundtrip — Make the attach→vault loop actually close (the \"does it work\" bug)", "why": "The ability bar's ＋ATTACH and vault read from DIFFERENT stores, so nothing attached ever appears in the vault: - ATTACH (araya-file-upload.mjs ~line 291) writes table `araya_documents` + storage bucket `araya-documents`. - VAULT (vault-api.mjs line 131-132) reads table `vault_items` + storage bucket `vault`. Two tables, two buckets, never bridged. Commander S425: \"we've never once shared stuff to a vault, pulled it back up, looked at it, put it back.\" ENABLES: closes step 3 (VAULT) of WO-one-foundational-page-that-works; unblocks the foundational window; proves the attach/share/vault loop for every dash (the ability bar is inherited by all). DO: Pick ONE bridge and make the loop close (prefer the smallest that works, then note the unify path): 1. FASTEST: on attach, ALSO insert a `vault_items` row (and upload to the `vault` bucket) so the attached file shows in the vault immediately — OR 2. have vault-api's list (vault-api.mjs ~line 131) read a UNION of `vault_items` + `araya_documents` scoped to the caller — OR 3. UNIFY onto one table + one bucket (the real fix; bigger). State which you chose and why. Also wire ⤴SHARE (the \"out\" side) to push a vault item to a room/user (or at minimum a working share link) — today it's unproven. Keep user-scoping intact: vault-api scopes every read to the caller's verified identifiers (vault-api.mjs line 40, 131) — the attached rows MUST carry the same user_id/scope so a user can never see another user's files.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-auth-getuuid-door", "file": "WO-auth-getuuid-door.md", "title": "WO-auth-getuuid-door — Auth.getUUID(): the ONE identity door (sturdy-state stitch 2)", "what": "WO-auth-getuuid-door — Auth.getUUID(): the ONE identity door (sturdy-state stitch 2)", "why": "", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-board-bounty-field", "file": "WO-board-bounty-field.md", "title": "WO-board-bounty-field — put a $ bounty on board cards (the hiring plug)", "what": "WO-board-bounty-field — put a $ bounty on board cards (the hiring plug)", "why": "With $1M and hiring, the board becomes a marketplace: a card with a $ value = a paid task any human/contractor/agent can claim from the SAME queue CP2 just joined. Card already has `xp`; add money. DO: Add `bounty_usd` column to dev_board_tasks (migration, additive). Map xp->$ (interim: xp IS the bounty unit until $ set). Surface bounty on board-feed + the card UI. cloud_queue/claim already works — a paid claim is the same claim with a payout on complete+approve. Gate payout behind review (preview-only).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-build-vs-buy-chat-store", "file": "WO-build-vs-buy-chat-store.md", "title": "WO — Build-vs-buy verdict: Main Chat vs Discord · The Store vs Shopify (parity grade + forecast + cutoff)", "what": "WO — Build-vs-buy verdict: Main Chat vs Discord · The Store vs Shopify (parity grade + forecast + cutoff)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-buildguild-auth-gate-check", "file": "WO-buildguild-auth-gate-check.md", "title": "WO-buildguild-auth-gate-check — Fix the Build Guild login gate (GitHub · Google · magic link)", "what": "WO-buildguild-auth-gate-check — Fix the Build Guild login gate (GitHub · Google · magic link)", "why": "⚠️ Commander flagged VERY IMPORTANT (S441) — the gate to Build Guild is \"not good\"; the three login providers need checking. This is the FRONT DOOR: if people can't get in, nothing downstream matters (cockpits, tasks, onboarding all sit behind it). Pairs with the Supabase auth config fix already in FORWARD_PLAN Lane 1 (persistSession + autoRefreshToken + signOut scope:local — the \"loses users / can't log back in\" fix). DO: - Live-test each provider end-to-end on the Build Guild login: **GitHub OAuth · Google OAuth · magic-link email** — each must land the user IN with a WORKING, PERSISTED session (not a bounce, not a lost session). - Check the provider consoles against `DNA/MECHANICS_LOG_IDENTITY.md` gate map + provider registry: redirect URIs, client IDs/secrets, allowed domains, the magic-link email template + sender. - Record each console in `provider_passports` (DNA/PROVIDERS/_PASSPORT_FORM.md). - Fix what's broken. NEVER rotate a user password without notify + a working recovery door (magic link is the always-works door).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-calls-widget-real-buttons", "file": "WO-calls-widget-real-buttons.md", "title": "WO — Calls widget: make the \"Call back\" buttons real", "what": "WO — Calls widget: make the \"Call back\" buttons real", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-canonical-toolbar", "file": "WO-chat-canonical-toolbar.md", "title": "WO-chat-canonical-toolbar — Bring the ONE HUD dock to Main Chat", "what": "WO-chat-canonical-toolbar — Bring the ONE HUD dock to Main Chat", "why": "Commander flagged it TWICE (\"need normal toolbar… offbrand\"). The pink bug button was recolored (S446) but the nav is still Munia's own MenuBar, not the canonical CR dock (cr-frame.js / HUD_MERGE_BLUEPRINT). Doctrine: ONE HUD everywhere, never a second bar. This is the last OPEN chat chrome item. DECISION (Commander, S447): **PORT cr-frame.js into a real React dock component** (canonical ONE-HUD source, reusable as a shared package — NOT a MenuBar restyle/look-alike). Retire Munia's MenuBar carefully. Build unblocked. DO: 1. ✅ DECISION MADE (above): port the full cr-frame.js A-dock into React. Don't restyle MenuBar. 2. Read `100X_DEPLOYMENT/DNA/HUD_MERGE_BLUEPRINT.md` + `components/cr-frame.js` (vanilla JS A-dock) + memory feedback_toolbars-on-everywhere / feedback_hud-ux-doctrines. 3. Port the 5-door bottom dock into a React component (thumb-zone, identical every page); wire ARAYA door → in-chat ARAYA DM (already live), GO → search, DRAWER → app-drawer sheet. 4. Retire Munia's MenuBar bottom bar (mobile) + reconcile the desktop sidebar — no second bar (HUD_MERGE law). 5. Keep the emerald bug button OR fold it into the dock per the no-floating doctrine.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-chat-streaming-typed", "file": "WO-chat-streaming-typed.md", "title": "WO — Stream ARAYA's typed-chat replies (kill the dead-air stare)", "what": "WO — Stream ARAYA's typed-chat replies (kill the dead-air stare)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-cockpit-shell", "file": "WO-cockpit-shell.md", "title": "WO — Cockpit shell: import · view · add-ability · save (Johnny / Odin / Commander)", "what": "WO — Cockpit shell: import · view · add-ability · save (Johnny / Odin / Commander)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-commander-weak-widgets", "file": "WO-commander-weak-widgets.md", "title": "WO — Commander's 3 weak widgets: agent-activity, keys, files-empty-state", "what": "WO — Commander's 3 weak widgets: agent-activity, keys, files-empty-state", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-contacts-comms-spine", "file": "WO-contacts-comms-spine.md", "title": "foundational contacts + consent model — the spine a whole Communications app could grow from", "what": "Design (decision doc first, then build) a foundational contacts + visibility + consent system — who can see whose contacts, who can be found via a searchable directory, and who can message whom. Model the actual message/DM mechanics on the EXISTING, already-canonical DM flow (components/widget-dm.js + netlify/functions/dm-api.mjs — verdict: [[project_builder-revolution-build-guild]] BG-5, \"System A is CANONICAL\"), and copy proven visibility/consent PATTERNS from other platforms rather than inventing new ones: - Phone contacts: your list is LOCAL/private by default; nobody is auto-added to anyone else's. - Discord: DMs open automatically between mutual friends or shared-server members; a friend REQUEST is required outside that (mutual accept, not one-sided visibility). - Instagram/Meta: public vs private account toggle; non-mutual senders land in a separate \"message requests\" folder instead of the main inbox (consent-gated, not blocked outright). - LinkedIn: an explicit \"who can see my connections\" privacy setting, separate from having a connection at all. Core pieces to land: 1. Personal contacts are PRIVATE-BY-DEFAULT, owned per-user — populating your own contacts never leaks them into anyone else's view. 2. A searchable/discoverable directory is a SEPARATE, OPT-IN surface — a person chooses IF and HOW they're listed (public / room-only / invite-only / not listed). Default = NOT LISTED. 3. Messaging permission (\"can A message B\") extends the existing L0-L7 permission ladder ([[project_permission-ladder]]) with a consent edge: shared room/mission membership, mutual opt-in, or an explicit invite — never just \"both accounts exist in the system.\" 4. A message-request-style holding lane for the non-mutual case (Instagram pattern) instead of either a hard block or open inbox.", "why": "Commander (S432, 2026-08-11): \"we're gonna have to figure out our foundational contact system and who's allowed to view whose contacts... some sort of orchestrator on who talks to who because now we've got three different groups... people start populating their own contacts, we can't get them into everybody else's contacts... we also have to ask people who they want their contact listed to, if anyone.\" Trigger: the BG-5 identity bridge just shipped this session ([[project_builder-revolution-build-guild]]), meaning two previously-separate user pools (the main site's Supabase-auth users and Builder Revolution's Prisma-auth users) now share ONE identity, plus a third population (legal/case clients on the Guardian/Case Builder side) already lives in the same system. Verified live: `netlify/functions/contacts-api.mjs` has ZERO visibility/opt-in fields today — no privacy model exists at all, so nothing currently stops one population's contacts from being visible to another. Commander's own framing: \"this could turn into a whole communications app if we figure out a few things these other platforms are missing and add them\" — real ambition, but the instruction is explicit: copy what other platforms already solved, don't reinvent the wheel.", "where": "netlify/functions/contacts-api.mjs (add visibility/opt-in fields + consent-gated reads) · components/widget-contacts.wdo.js (client UI) · components/widget-dm.js + netlify/functions/dm-api.mjs (the reference message/consent flow to extend, not replace) · the identity layer the BG-5 bridge uses (Supabase Auth as sole issuer, verified JWT — see overkillkulture/builder-revolution PR #3, `supabase-bridge` NextAuth provider) · [[project_permission-ladder]] (L0-L7) for the consent-edge extension.", "who": "Claude direct for the decision doc + schema; human-or-ai for the \"audit other platforms\" research slice (browser-only friendly)", "status": "open", "claimer": "", "lane_raw": "INSIDE", "next": "", "routed": "UNROUTED", "project": "Communications", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-cross-ai-bootstrap-relay", "file": "WO-cross-ai-bootstrap-relay.md", "title": "Copy your work out of ANY AI → machine turns it into a leveled bootstrap WO with an 8-facet index name → paste into the next AI and it takes off STATUS: blocked LANE: NEXT", "what": "Copy your work out of ANY AI → machine turns it into a leveled bootstrap WO with an 8-facet index name → paste into the next AI and it takes off STATUS: blocked LANE: NEXT", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-default-for-tier-packs", "file": "WO-default-for-tier-packs.md", "title": "WO — default_for_tier: buying L1/L2/L3 auto-binds the tier pack as your rail", "what": "WO — default_for_tier: buying L1/L2/L3 auto-binds the tier pack as your rail", "why": "", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-dual-mode-personal-public-line", "file": "WO-dual-mode-personal-public-line.md", "title": "ONE number that knows the owner (personal assistant) vs the public (receptionist) STATUS: open LANE: NEXT-BIG", "what": "ONE number that knows the owner (personal assistant) vs the public (receptionist) STATUS: open LANE: NEXT-BIG", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT-BIG", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-entity-trust-professional", "file": "WO-entity-trust-professional.md", "title": "WO-entity-trust-professional — Entity/trust bones — book a licensed pro to ratify the holding structure", "what": "WO-entity-trust-professional — Entity/trust bones — book a licensed pro to ratify the holding structure", "why": "Section 4: everything is implicitly Commander-personal plus one LLC. Trust/holdco layer needs a licensed professional; standard boring structures only. DO: Commander: pick a business attorney or CPA (Idaho or WA), one consult on: trust to holdco to opco shape, which entity owns ARAYA/brands/courses, where each revenue stream lands. Bring THE_ORG_BONES.md section 4 as the agenda.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-export-components-arm-araya-os", "file": "WO-export-components-arm-araya-os.md", "title": "WO-export-components-arm-araya-os — export every system/component as its own object → widget → ARAYA OS capability", "what": "WO-export-components-arm-araya-os — export every system/component as its own object → widget → ARAYA OS capability", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-external-dev-mvp-drop-anywhere", "file": "WO-external-dev-mvp-drop-anywhere.md", "title": "WO — Vault \"drop-anywhere\" overlay (GOOD FIRST PR / external-dev MVP)", "what": "WO — Vault \"drop-anywhere\" overlay (GOOD FIRST PR / external-dev MVP)", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-file-indexer-videographer-naming", "file": "WO-file-indexer-videographer-naming.md", "title": "WO — The file-indexer machine: \"index files to divinity\" with videographer-grade names + tags", "what": "WO — The file-indexer machine: \"index files to divinity\" with videographer-grade names + tags", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-files-widget-vault-store-unify", "file": "WO-files-widget-vault-store-unify.md", "title": "WO-files-widget-vault-store-unify — the \"Files\" widget shows a DIFFERENT store than the vault ARAYA speaks", "what": "WO-files-widget-vault-store-unify — the \"Files\" widget shows a DIFFERENT store than the vault ARAYA speaks", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-house--claude-ledger", "file": "WO-fill-organ-house--claude-ledger.md", "title": "WO-fill-organ-house--claude-ledger — Fill LEDGER organ for HOUSE .claude", "what": "WO-fill-organ-house--claude-ledger — Fill LEDGER organ for HOUSE .claude", "why": "HOUSE node '.claude' is missing LEDGER organ (completeness: 80.0%) DO: Implement LEDGER for HOUSE/.claude: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-house--consciousness-gauge", "file": "WO-fill-organ-house--consciousness-gauge.md", "title": "WO-fill-organ-house--consciousness-gauge — Fill GAUGE organ for HOUSE .consciousness", "what": "WO-fill-organ-house--consciousness-gauge — Fill GAUGE organ for HOUSE .consciousness", "why": "HOUSE node '.consciousness' is missing GAUGE organ (completeness: 80.0%) DO: Implement GAUGE for HOUSE/.consciousness: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-11-0-board", "file": "WO-fill-organ-pcf-11-0-board.md", "title": "WO-fill-organ-pcf-11-0-board — Fill BOARD organ for PCF 11.0", "what": "WO-fill-organ-pcf-11-0-board — Fill BOARD organ for PCF 11.0", "why": "PCF node '11.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/11.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-11-0-heartbeat", "file": "WO-fill-organ-pcf-11-0-heartbeat.md", "title": "WO-fill-organ-pcf-11-0-heartbeat — Fill HEARTBEAT organ for PCF 11.0", "what": "WO-fill-organ-pcf-11-0-heartbeat — Fill HEARTBEAT organ for PCF 11.0", "why": "PCF node '11.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/11.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-12-0-board", "file": "WO-fill-organ-pcf-12-0-board.md", "title": "WO-fill-organ-pcf-12-0-board — Fill BOARD organ for PCF 12.0", "what": "WO-fill-organ-pcf-12-0-board — Fill BOARD organ for PCF 12.0", "why": "PCF node '12.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/12.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-12-0-heartbeat", "file": "WO-fill-organ-pcf-12-0-heartbeat.md", "title": "WO-fill-organ-pcf-12-0-heartbeat — Fill HEARTBEAT organ for PCF 12.0", "what": "WO-fill-organ-pcf-12-0-heartbeat — Fill HEARTBEAT organ for PCF 12.0", "why": "PCF node '12.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/12.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-13-0-board", "file": "WO-fill-organ-pcf-13-0-board.md", "title": "WO-fill-organ-pcf-13-0-board — Fill BOARD organ for PCF 13.0", "what": "WO-fill-organ-pcf-13-0-board — Fill BOARD organ for PCF 13.0", "why": "PCF node '13.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/13.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-13-0-heartbeat", "file": "WO-fill-organ-pcf-13-0-heartbeat.md", "title": "WO-fill-organ-pcf-13-0-heartbeat — Fill HEARTBEAT organ for PCF 13.0", "what": "WO-fill-organ-pcf-13-0-heartbeat — Fill HEARTBEAT organ for PCF 13.0", "why": "PCF node '13.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/13.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-3-0-board", "file": "WO-fill-organ-pcf-3-0-board.md", "title": "WO-fill-organ-pcf-3-0-board — Fill BOARD organ for PCF 3.0", "what": "WO-fill-organ-pcf-3-0-board — Fill BOARD organ for PCF 3.0", "why": "PCF node '3.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/3.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-3-0-heartbeat", "file": "WO-fill-organ-pcf-3-0-heartbeat.md", "title": "WO-fill-organ-pcf-3-0-heartbeat — Fill HEARTBEAT organ for PCF 3.0", "what": "WO-fill-organ-pcf-3-0-heartbeat — Fill HEARTBEAT organ for PCF 3.0", "why": "PCF node '3.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/3.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-4-0-board", "file": "WO-fill-organ-pcf-4-0-board.md", "title": "WO-fill-organ-pcf-4-0-board — Fill BOARD organ for PCF 4.0", "what": "WO-fill-organ-pcf-4-0-board — Fill BOARD organ for PCF 4.0", "why": "PCF node '4.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/4.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-4-0-state", "file": "WO-fill-organ-pcf-4-0-state.md", "title": "WO-fill-organ-pcf-4-0-state — Fill STATE organ for PCF 4.0", "what": "WO-fill-organ-pcf-4-0-state — Fill STATE organ for PCF 4.0", "why": "PCF node '4.0' is missing STATE organ (completeness: 60.0%) DO: Implement STATE for PCF/4.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-5-0-board", "file": "WO-fill-organ-pcf-5-0-board.md", "title": "WO-fill-organ-pcf-5-0-board — Fill BOARD organ for PCF 5.0", "what": "WO-fill-organ-pcf-5-0-board — Fill BOARD organ for PCF 5.0", "why": "PCF node '5.0' is missing BOARD organ (completeness: 80.0%) DO: Implement BOARD for PCF/5.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-7-0-board", "file": "WO-fill-organ-pcf-7-0-board.md", "title": "WO-fill-organ-pcf-7-0-board — Fill BOARD organ for PCF 7.0", "what": "WO-fill-organ-pcf-7-0-board — Fill BOARD organ for PCF 7.0", "why": "PCF node '7.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/7.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-7-0-state", "file": "WO-fill-organ-pcf-7-0-state.md", "title": "WO-fill-organ-pcf-7-0-state — Fill STATE organ for PCF 7.0", "what": "WO-fill-organ-pcf-7-0-state — Fill STATE organ for PCF 7.0", "why": "PCF node '7.0' is missing STATE organ (completeness: 60.0%) DO: Implement STATE for PCF/7.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-9-0-board", "file": "WO-fill-organ-pcf-9-0-board.md", "title": "WO-fill-organ-pcf-9-0-board — Fill BOARD organ for PCF 9.0", "what": "WO-fill-organ-pcf-9-0-board — Fill BOARD organ for PCF 9.0", "why": "PCF node '9.0' is missing BOARD organ (completeness: 80.0%) DO: Implement BOARD for PCF/9.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fundraising-business-plan-define", "file": "WO-fundraising-business-plan-define.md", "title": "WO-fundraising-business-plan-define — DEFINE: Fundraising & Business Plan", "what": "WO-fundraising-business-plan-define — DEFINE: Fundraising & Business Plan", "why": "North-Star chunk: Fundraising & Business Plan. Get everyone organized + running as a business; build the business plan + the path to raise money on tech. Make the reports paid users want to see before they invest. Paid users ar ENABLES: completing this turns 'Fundraising & Business Plan' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/fundraising-business-plan.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-funnel-template-standard", "file": "WO-funnel-template-standard.md", "title": "WO — The ONE Funnel/Page Template + GATE (the center point of reference)", "what": "WO — The ONE Funnel/Page Template + GATE (the center point of reference)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-gh-window-explosion", "file": "WO-gh-window-explosion.md", "title": "WO — Kill the gh.exe window explosion (~30 console windows flash ~hourly)", "what": "WO — Kill the gh.exe window explosion (~30 console windows flash ~hourly)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-green-projects-live-store", "file": "WO-green-projects-live-store.md", "title": "WO-green-projects-live-store — Supabase table + CRUD for green projects (IF surface revives)", "what": "WO-green-projects-live-store — Supabase table + CRUD for green projects (IF surface revives)", "why": "PR #1140 (S427, closed S453 by merge-captain triage) built the whole backend (S427_green_projects.sql migration + green-projects-api.mjs CRUD) but the demand side is dead — the widget is unmounted, and merging a live DB+API for a dead surface violates the no-orphan law. The code is good; the timing is wrong. SALVAGE: closed PR #1140 (branch opencode-905-green-project-storage preserved) — lift `S427_green_projects.sql` + `green-projects-api.mjs` nearly as-is when this unblocks.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-guardian-forge-opensource-tools", "file": "WO-guardian-forge-opensource-tools.md", "title": "WO-guardian-forge-opensource-tools — Package Guardian Forge's open-source tools to sell on ARAYA OS", "what": "WO-guardian-forge-opensource-tools — Package Guardian Forge's open-source tools to sell on ARAYA OS", "why": "Guardian Forge (Unite The Movement) is meant to be the place open-source tools live and spread — but tools that aren't packaged and priced don't fund the movement. Turning the Guardian Forge open-source toolset into clean, sellable listings on ARAYA OS gives the mission a revenue engine while keeping the tools open (sell the build/support/hosting, not the license). It pairs with the electrical-devices marketplace as the \"tools\" half of the sourcing story. DO: Catalog the Guardian Forge open-source tools, decide the open-source-friendly monetization (support / kits / hosting / done-for-you), and list them on ARAYA OS through the seller funnel. See RING 3.", "where": "Build INTO the ONE shell (Guardian Forge storefront section in pulse); reuse the seller funnel / Stripe — no second cart.", "who": "COMMANDER-authored; buyer-facing catalog public; contributor tools credited. Unclaimed. SPAWN: contributor-submission flow (let outside builders add tools to the Forge), affiliate/XP share-loop. RELATED: WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, project_unite-the-movement-blueprint, project_creator-tools-platform-vision, project_three-bucket-contributor-doctrine, project_508c1a-structure SOURCE: Commander dictation S426 — \"open source tools for guardian forge to sell on araya os.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-guardian-video-cta-landing", "file": "WO-guardian-video-cta-landing.md", "title": "WO — Guardian video-CTA landing (where warm traffic from the pro-se videos lands)", "what": "WO — Guardian video-CTA landing (where warm traffic from the pro-se videos lands)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-guild-door-roundtrip", "file": "WO-guild-door-roundtrip.md", "title": "WO — Build Guild door: arrive signed-in, always a way home", "what": "WO — Build Guild door: arrive signed-in, always a way home", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-health-detox-frequency-tek-marketplace", "file": "WO-health-detox-frequency-tek-marketplace.md", "title": "WO-health-detox-frequency-tek-marketplace — Curated health/detox/frequency tek storefront on ARAYA OS", "what": "WO-health-detox-frequency-tek-marketplace — Curated health/detox/frequency tek storefront on ARAYA OS", "why": "There's huge, scattered demand for health/detox/frequency tek — PEMF, structured water, parasite/detox cleanse, peptides, frequency/Rife-style devices — sold in a hundred sketchy corners with no trusted, curated one-spot. Aggregating reputable makers into a single ARAYA OS storefront gives buyers a vetted place and makers distribution + payout, feeding the same 20%-cut engine as the electrical + Guardian Forge marketplaces. COMPLIANCE IS PART OF THE JOB (see rails) — these categories carry real FDA/FTC claim risk. DO: Curate the categories, source + contact reputable makers, and stand up a compliant curated storefront that sells through the seller funnel — with a claims/compliance guard baked in from step one. See RING 3.", "where": "Build INTO the ONE shell (Health Tek storefront section in pulse); reuse the seller funnel / Stripe — no second cart.", "who": "COMMANDER-authored; buyer catalog public; maker outreach commander-only. Unclaimed. SPAWN: per-category deep-dive cards; a compliance/disclaimer-template card (reusable across all product marketplaces). RELATED: WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, WO-guardian-forge-opensource-tools, project_offerings-consolidation, project_creator-tools-platform-vision SOURCE: Commander dictation S426 — \"all health / detox / parasite cleanse tek, PEMF, structured water, peptide frequency, all that stuff.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-human-on-the-phone-per-product-define", "file": "WO-human-on-the-phone-per-product-define.md", "title": "WO-human-on-the-phone-per-product-define — DEFINE: Human on the Phone per Product", "what": "WO-human-on-the-phone-per-product-define — DEFINE: Human on the Phone per Product", "why": "North-Star chunk: Human on the Phone per Product. A real human prepared to answer the call for every product. Commander needs a good WIRED headset (Bluetooth is too dinky, dies). ENABLES: completing this turns 'Human on the Phone per Product' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/human-on-the-phone-per-product.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-identity-rekey-email-to-uuid", "file": "WO-identity-rekey-email-to-uuid.md", "title": "WO-identity-rekey-email-to-uuid — re-key the email-keyed backends onto the Supabase UUID", "what": "WO-identity-rekey-email-to-uuid — re-key the email-keyed backends onto the Supabase UUID", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-import-starting-point", "file": "WO-import-starting-point.md", "title": "WO — THE IMPORT STARTING POINT (the universal \"get your data in\" step)", "what": "WO — THE IMPORT STARTING POINT (the universal \"get your data in\" step)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-interface-progression-engine", "file": "WO-interface-progression-engine.md", "title": "WO — THE PROGRESSION ENGINE (the interface advances with the user)", "what": "WO — THE PROGRESSION ENGINE (the interface advances with the user)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-landing-page-one-mold", "file": "WO-landing-page-one-mold.md", "title": "make \"Welcome to the Revolution\" the ONE landing mold; clone it for Johnny/Rachel STATUS: open LANE: NEXT", "what": "make \"Welcome to the Revolution\" the ONE landing mold; clone it for Johnny/Rachel STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-leads-registry-conflict-commander-ops", "file": "WO-leads-registry-conflict-commander-ops.md", "title": "WO-leads-registry-conflict-commander-ops — leads slot routes to commander-ops, not widget-leads2 (de-dupe)", "what": "WO-leads-registry-conflict-commander-ops — leads slot routes to commander-ops, not widget-leads2 (de-dupe)", "why": "Wave-3 comb (S442) C2-split found on `leads`: 1. REGISTRY CONFLICT — DNA/WIDGET_REGISTRY.json id 'leads' says render:'url' → '/commander-ops.html#leads', widget:null. It does NOT know widget-leads2.js exists and routes the leads slot to commander-ops (which CANONICAL_REGISTRY says is NOT the dashboard). Two registries disagree on what 'leads' is. 2. LIVE DUPLICATE — commander-ops.html still carries its own hand-rolled leads panel (loadOpsLeads/markOpsLead hitting /.netlify/functions/araya-leads directly) — the exact fork my/index.html declared dead. Two live leads implementations. DO: - Point the leads registry row at widget-leads2.js (the shipped widget) instead of the commander-ops URL; verify the slot opens the widget on prod. - Decide commander-ops.html's leads panel: retire it (redirect to the widget) or explicitly mark it a separate ops view — but it must not be a second silent implementation of the same data. - Re-check the org chart for a leads name_collision cluster and clear it.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-main-chat-punchlist-s443", "file": "WO-main-chat-punchlist-s443.md", "title": "WO — MAIN CHAT PUNCH LIST (everything wrong, carded) · S443 · 2026-08-17", "what": "WO — MAIN CHAT PUNCH LIST (everything wrong, carded) · S443 · 2026-08-17", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-merge-captain-honor-block", "file": "WO-merge-captain-honor-block.md", "title": "WO-merge-captain-honor-block — Merge Captain must FAIL a PR that carries a standing content BLOCK", "what": "WO-merge-captain-honor-block — Merge Captain must FAIL a PR that carries a standing content BLOCK", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-mesh-comms-builders-as-nodes-define", "file": "WO-mesh-comms-builders-as-nodes-define.md", "title": "WO-mesh-comms-builders-as-nodes-define — DEFINE: Mesh Comms — builders as nodes", "what": "WO-mesh-comms-builders-as-nodes-define — DEFINE: Mesh Comms — builders as nodes", "why": "North-Star chunk: Mesh Comms — builders as nodes. Every builder walks around with a radio and becomes a NODE. Explore reticulum/LoRa (range is the problem). A SIP-calling VPS telephone system is the backbone of everything; an offl ENABLES: completing this turns 'Mesh Comms — builders as nodes' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/mesh-comms-builders-as-nodes.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-music-every-forge", "file": "WO-music-every-forge.md", "title": "WO-music-every-forge — music becomes a layer across ALL 7 forges, not just Signal", "what": "Commander S412: 'music's gonna end up being part of every other forge.' Make the music widget/ability mountable in every forge (Reality/Creation/Signal/Guardian/Wealth/Character/Infinity) — each forge gets its frequency + a music surface. Music is a cross-cutting shell ability, not a page.", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-newsreader-demo-fallback", "file": "WO-newsreader-demo-fallback.md", "title": "WO-newsreader-demo-fallback — give widget-news-reader an offline demo so the crew can audit it", "what": "WO-newsreader-demo-fallback — give widget-news-reader an offline demo so the crew can audit it", "why": "news-reader is mount-C (demoData missing) so it can't be cheap-audited; add demo data to flip it to B. DO: add a non-null demoData fixture + wire renderCard to use it when the atom-feed fetch 401s.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-offerings-polish-johnny-rachel-l2", "file": "WO-offerings-polish-johnny-rachel-l2.md", "title": "WO — Polish the offerings (L1/L2/L3 sale-ready) + finish the Johnny/Rachel Level-2 suite", "what": "WO — Polish the offerings (L1/L2/L3 sale-ready) + finish the Johnny/Rachel Level-2 suite", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-opensource-electrical-devices-marketplace", "file": "WO-opensource-electrical-devices-marketplace.md", "title": "WO-opensource-electrical-devices-marketplace — Aggregate open-source electrical devices (from Instagram) into ONE storefront on ARAYA OS", "what": "WO-opensource-electrical-devices-marketplace — Aggregate open-source electrical devices (from Instagram) into ONE storefront on ARAYA OS", "why": "There's a wave of open-source electrical / hardware devices all over Instagram with no unified place to buy them — makers are scattered, buyers can't find them, and none of it is monetized. Aggregating them into ONE spot on ARAYA OS gives makers distribution + a payout, gives buyers a trusted catalog, and feeds the platform's 20%-cut engine. It's also the sourcing arm for Guardian Forge (see WO-guardian-forge-opensource-tools). DO: Build a sourced list of open-source electrical-device makers seen on Instagram, run outreach to invite them to list, and stand up a single catalog storefront on ARAYA OS that sells through the seller funnel. See RING 3.", "where": "Build INTO the ONE shell (storefront widget/page in pulse), reuse the seller funnel for checkout — do not build a second cart.", "who": "COMMANDER-authored; maker-facing outreach; buyer-facing catalog is public. Unclaimed. SPAWN: WO-guardian-forge-opensource-tools (sibling), WO-health-detox-frequency-tek-marketplace (sibling), buyer-side cart polish. RELATED: WO-seller-onboarding-cart-funnel, project_unite-the-movement-blueprint, project_offerings-consolidation, project_creator-tools-platform-vision, project_affiliate-fractal-system, project_ark-electronics-kit SOURCE: Commander dictation S426 — \"contacting all open source electrical devices I'm seeing everywhere on Instagram to sell in 1 spot.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-orphan-widgets-decision", "file": "WO-orphan-widgets-decision.md", "title": "WO-orphan-widgets-decision — Decide the 3 orphan widgets: load, archive, or finish (analytics / news-reader / voice)", "what": "WO-orphan-widgets-decision — Decide the 3 orphan widgets: load, archive, or finish (analytics / news-reader / voice)", "why": "Widget ledger S420b: 3 widget files exist that the shell never loads — dead or stranded code, worst gap scores in the seed pyramid (15-17). Every census cycle recounts them until decided. DO: Commander decides per orphan: (a) register + load it (V1 row + script tag), (b) archive to components/widgets/_archive/, or (c) card it for finishing. widget-voice may be superseded by the araya-voice.html text fallback shipped S420b.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-p4-store-owner-clone", "file": "WO-p4-store-owner-clone.md", "title": "WO-p4-store-owner-clone — P4 clone/customize/publish rebuilt on the canonical pack registry", "what": "WO-p4-store-owner-clone — P4 clone/customize/publish rebuilt on the canonical pack registry", "why": "PR #889 (S416, closed S453 by merge-captain triage) built the whole flow on a NEW parallel Supabase schema — a no-8th-copy violation of CANONICAL_STORES.md (packs canonical = DNA/PACK_REGISTRY.json, frozen S451). Capability still wanted per the locked tier map; the branch (opencode-26-store-clone) is preserved as reference but must be rebuilt on the canonical stores, not merged.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pack-backlog-widgets", "file": "WO-pack-backlog-widgets.md", "title": "WO-pack-backlog-widgets — Build the pack-backlog widgets", "what": "WO-pack-backlog-widgets — Build the pack-backlog widgets", "why": "S448 ran the pack bridge live — 15 grants landed in widget_grants, but ~half of every owned pack resolved to NOTHING because the widget doesn't exist in widget_catalog. Johnny/Rachel/Odin are missing real business surfaces (files, case, earn, booking, etc.). Each is one tracked object here, not 10 scattered docs. BACKLOG (ranked by how many owned packs request it — from apply-pack-v2 dry-run): - files (4 packs) - case (3 packs) - earn (3 packs) # note: 'earn' historically aliased to widget-store — confirm one canonical id - links (3 packs) - projects (2 packs) - workdesk (2 packs) - scorecard (2 packs) - vault (1 pack) # NOTE: widget-vault already exists as an ORPHAN file per WIDGET_LEDGER — likely activation-only - booking (1 pack) # Rachel's ArtWorks Land Lab core surface - doc (1 pack) (DOORS, not widgets — do NOT build as widgets: reception, page. They route to receptionist.html / builder page.) DO: 1. TRIAGE FIRST (this shrinks the job): for each backlog id, check components/widgets/ + DNA/WIDGET_LEDGER.csv. Split into (A) file EXISTS but not in widget_catalog → just needs a catalog row + active=true (activation), vs (B) truly unbuilt → needs a widget built to GOLD_STANDARD (DNA/WIDGET_FACTORY.md). 2. For (A) activation: insert widget_catalog row (widget_id bare, title, pitch, cost_class, active=true), verify it renders. 3. For (B) build: build per WIDGET_FACTORY.md, add catalog row, wire into shell. 4. Reconcile the 'earn' vs 'widget-store' alias — pick ONE canonical widget_id, update ALIASES in apply-pack-v2.py. 5. Re-run `C:\\Python313\\python.exe DNA/apply-pack-v2.py --commit` — each newly-catalogued widget now grants automatically to the packs that want it (idempotent; only writes the new ones). Verify grants land by readback.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pack-owner-toggle-collapse", "file": "WO-pack-owner-toggle-collapse.md", "title": "WO — Pack owners: collapse the 3-lane mode dial to My Cockpit / Public preview", "what": "WO — Pack owners: collapse the 3-lane mode dial to My Cockpit / Public preview", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pattern-theory-posters", "file": "WO-pattern-theory-posters.md", "title": "WO — Pattern Theory Posters (Class 016 product + \"upgrade every character poster\")", "what": "WO — Pattern Theory Posters (Class 016 product + \"upgrade every character poster\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-communication", "file": "WO-pillar-communication.md", "title": "WO-pillar-communication — SEEDABLE BUSINESS: mesh radios → off-grid comms network (Pillar 6 of 13)", "what": "WO-pillar-communication — SEEDABLE BUSINESS: mesh radios → off-grid comms network (Pillar 6 of 13)", "why": "When the grid/cell network fails, coordination fails — you can't run water/energy/security response without comms. Meshtastic (LoRa) nodes are cheap (~$25-40), need no infrastructure, and this is an ACTIVE build in sovereignty-hub (issue #5 mesh bridge). Seed→scale: sell/configure radios → run relay nodes → a resilient community mesh with offline messaging + AI-over-LoRa. SEED (~1 person): Buy/flash/configure Meshtastic radios and sell them set-up-and-ready to neighbors. Start cost = a few radios (~$100-150 for 3-4 units). SCALE (community-critical): A community mesh — solar-powered relay nodes on high points, offline group messaging, emergency broadcast, and the AI-over-LoRa bridge — the comms backbone every other pillar coordinates over. REVENUE (C6): SEED — a $30 radio sold configured-and-ready for $70-90 (setup labor is the value-add). Setup service $20-40/unit. 10 units/mo = ~$500-800. SCALE — network membership ($5-10/mo per node for relay/maintenance access — recurring), relay-node install ($100-300), emergency-broadcast service for the community. Best margin: the setup service (labor on cheap hardware); best recurring: network membership. GOVERNANCE MODULE: Seed = member owns their radios. Scale = the mesh becomes a \"comms co-op\" node — relay-host members get credits in the pillar ledger; channel/frequency/moderation rules and the emergency-broadcast protocol are set in the charter (who can trigger an all-node alert = a critical governance decision); abuse/spam on the mesh routes to the Governance dispute module. Encryption keys managed per the No-Single-Capture doctrine. TIES: ENERGY (solar relay nodes — direct dependency) · SECURITY (emergency coordination, alerts) · GOVERNANCE (voting/announcements can ride the mesh) · KNOWLEDGE (AI-over-LoRa serves offline knowledge) · every pillar coordinates over comms in a crisis. DO: (1) Publish the Meshtastic setup guide + BOM from Pillar 6 (leverage active issue #5). (2) Member flashes/configures 3-4 radios, sells set up to neighbors. (3) Stand up a radio store + network-membership page (Trade marketplace). (4) Sell to 5 neighbors, get 3 nodes talking on one channel. (5) Log the comms-co-op charter stub + broadcast protocol.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-culture", "file": "WO-pillar-culture.md", "title": "WO-pillar-culture — SEEDABLE BUSINESS: music/story/events studio → the reason the community holds (Pillar 13 of 13)", "what": "WO-pillar-culture — SEEDABLE BUSINESS: music/story/events studio → the reason the community holds (Pillar 13 of 13)", "why": "Culture is why a community is worth surviving FOR — the pillar that turns a group of self-sufficient households into a people. It's also the growth engine: music, story, and events are the top-of-funnel that brings new members in (ties to the influencer/podcast push). Least \"survival-critical\" in an acute sense, but the pillar that prevents the community from dissolving once fed and safe. Seed→scale: content/music + one event → a studio + event series → the community's media + identity engine. SEED (~1 person): Produce music (the ElevenLabs music-generation pipeline is LIVE), art, or story content + host one community event (open mic, story night, market-day entertainment). Start cost = ~$0-100 (existing pipeline + a venue that's a living room/park). SCALE (community-critical): A media + events engine — a studio, a podcast/YT channel (the funding-plan engine), event series, and the shared story/brand that gives the community identity and recruits new members. REVENUE (C6): SEED — custom songs/content ($20-100/piece via the live music pipeline), event tickets/donations ($5-15/head), merch/art sales. SCALE — content channel (podcast/YT ad + sponsor revenue — the existing house→podcast funding plan), event series, brand/merch, paid commissions, patron/membership ($5-15/mo). HONESTY: culture monetizes UNEVENLY — most content earns little; a few hits + events + the channel carry it. Best margin: digital content (music pipeline = near-zero marginal cost); best recurring: patron membership + channel revenue. It also has the highest INDIRECT value: it feeds the funnel that grows every other pillar's customer base. GOVERNANCE MODULE: Seed = member owns their creative work + IP. Scale = a shared studio/brand becomes a \"culture co-op\" node — creators retain IP but licensing/revenue-share for shared-brand work is a charter clause; event proceeds split (creator/community-fund) voted 1-member-1-vote; content standards (what represents the community) + brand use are charter clauses; disputes over credit/royalties route to Governance. Balance the gift-economy ethos (free community events) with sustainability (paid channel/commissions). TIES: KNOWLEDGE (story is how knowledge/values transmit) · TRADE (merch/tickets sell through marketplace) · COMMUNICATION (events announced over the mesh) · every pillar's story gets told here; Culture is the funnel that recruits members INTO all 12 other pillars. DO: (1) Package a content/music offering using the LIVE music-generation pipeline (songs-table + player already shipped) from Pillar 13. (2) Member produces 3 pieces + plans one community event. (3) Stand up a content-sales + event-ticket page (Trade marketplace). (4) Sell 5 pieces or host one event with real attendance. (5) Log the culture-co-op charter stub + IP/revenue-share clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-energy", "file": "WO-pillar-energy.md", "title": "WO-pillar-energy — SEEDABLE BUSINESS: battery reconditioning → the block's microgrid (Pillar 4 of 13)", "what": "WO-pillar-energy — SEEDABLE BUSINESS: battery reconditioning → the block's microgrid (Pillar 4 of 13)", "why": "Energy is the multiplier for every other pillar — water pumps, grow lights, refrigeration (food+medicine), comms all die without power. Battery reconditioning turns free/cheap scrap (dead 18650s, car/forklift batteries) into sellable storage — high margin from a near-zero material cost. Seed→scale: reconditioned power banks → solar-kit installs → a shared microgrid. SEED (~1 person): Recondition salvaged 18650 cells / lead-acid batteries into power banks + small solar phone/light kits. Start cost < $250 (a charger/analyzer + salvage cells often free). SCALE (community-critical): Solar-kit installs and a battery-bank microgrid that powers critical loads (well pump, fridge, comms hub) through outages — the member becomes the block's power keeper. REVENUE (C6): SEED — a reconditioned power bank costs ~$5-10 in salvaged cells, sells $40-80 (5-8x). Small solar+battery light kit: ~$30 cost → $90-120. 10 units/mo = ~$500-900. SCALE — solar-kit installs ($300-2000 per home, labor + parts markup), microgrid membership ($20-40/mo for backup-power access), EV/tool charging service. Best margin: reconditioned banks (salvage input); best recurring: microgrid-access membership. GOVERNANCE MODULE: Seed = member owns their gear. Scale = a shared battery bank/microgrid becomes an \"energy co-op\" node — capital contributors get proportional shares in the pillar ledger; load-priority rules (who gets power in a shortage — medical first) are set in the charter and voted 1-member-1-vote; safety (fire/electrical) is a mandatory certified-install clause; billing disputes route to the Governance module. TIES: WATER (pumps/UV) · FOOD (refrigeration, grow lights) · MEDICINE (refrigeration for meds, PEMF devices) · COMMUNICATION (powers the mesh hub) · MANUFACTURING (charges tools) — Energy underwrites nearly every pillar. DO: (1) Publish the reconditioning + small-solar-kit BOM from Pillar 4. (2) Member reconditions a batch, builds 2-3 kits. (3) Stand up a store/service page (Trade marketplace). (4) Sell to 5 neighbors; note who wants microgrid backup. (5) Log the energy-co-op charter stub + safety clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-food", "file": "WO-pillar-food.md", "title": "WO-pillar-food — SEEDABLE BUSINESS: from one seed tray to the block's food (Pillar 2 of 13)", "what": "WO-pillar-food — SEEDABLE BUSINESS: from one seed tray to the block's food (Pillar 2 of 13)", "why": "The most literal seed→survival pillar. A tray of microgreens goes seed→harvest in 7-10 days, so cash comes in the FIRST week. Food is the second thing a community dies without. Seed→scale: one microgreen tray → weekly herb/greens subscription → aquaponics + preservation that carries households through a supply-chain break. SEED (~1 person): One shelf of microgreen/herb trays (sunflower, pea, basil). Seed-to-sale in ~10 days. Start cost < $150 (trays, seed, soil, a shelf). SCALE (community-critical): A neighborhood CSA — weekly veg/herb boxes, an aquaponics loop (fish + greens), and a preservation kitchen (canning/drying) so food doesn't spike-and-rot. The member becomes the block's grower. REVENUE (C6): SEED — microgreens are the highest $/sqft crop: a $0.50 tray of seed yields ~$20-30 of greens; restaurants/neighbors pay $20-30/lb. 20 trays/week on a rotation = ~$300-500/mo at near-zero marginal cost. Add a $25-40/mo weekly herb-box subscription. SCALE — CSA boxes at $30-50/week x 15 households = $450-750/week; preservation/value-add (dried herbs, canned goods) sells at 4-6x raw cost. Best margin: microgreens (fastest cycle) at seed, CSA subscription at scale (predictable recurring). GOVERNANCE MODULE: Seed = member owns their grow. Scale = when land/water/aquaponics is shared, it becomes a \"grow co-op\" node — contributors of land/labor/capital get proportional shares recorded in the pillar ledger; harvest-split and pricing decided by 1-member-1-vote on the co-op board; crop-failure/liability disputes route to the Governance dispute module. Food-safety standard is a mandatory clause in the charter. TIES: WATER (irrigation/aquaponics is water-hungry — pair with Pillar 1) · ENERGY (grow lights, pumps) · MEDICINE (nutrition = preventive health) · TRADE (CSA sells through marketplace) · KNOWLEDGE (grow guides) · CULTURE (community harvest events). DO: (1) Publish the microgreen + herb starter BOM from Pillar 2. (2) Member sets up one grow shelf, runs one 10-day cycle. (3) Stand up a CSA/herb-box subscription page on the Trade marketplace. (4) Sell the first harvest to 5 neighbors; enroll 2 on the weekly box. (5) Log the grow-co-op charter stub.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-governance", "file": "WO-pillar-governance.md", "title": "WO-pillar-governance — SEEDABLE BUSINESS: charter-as-a-service → the community operating system (Pillar 11 of 13)", "what": "WO-pillar-governance — SEEDABLE BUSINESS: charter-as-a-service → the community operating system (Pillar 11 of 13)", "why": "Commander explicitly flagged \"governance modules.\" Governance is the pillar the other 12 all DEPEND ON — every pillar card above ends with \"route disputes to the Governance module\" and \"voted 1-member-1-vote.\" Without a shared, trusted way to decide/own/resolve, every co-op fractures the moment there's money or conflict. This pillar productizes the governance modules the other 12 reuse. Seed→scale: facilitate one charter → run voting/dispute for a few co-ops → the community's operating system. SEED (~1 person): A facilitator who helps a group write its charter (ownership shares, decision rules, dispute process) using standard templates, and sets up a simple voting + dispute board. Start cost = ~$0 (templates + a shared doc/board). SCALE (community-critical): The shared governance stack — charter templates, a voting system, a dispute-resolution process, and the pillar-ledger of ownership/shares — that all 12 other co-ops plug into. The member becomes the community's clerk/facilitator. REVENUE (C6): SEED — charter facilitation flat fee ($75-200 per group), dispute-mediation fee ($30-75/session). SCALE — governance-platform subscription per co-op ($10-25/mo for hosted voting + ledger — recurring across all 12 pillars' co-ops), mediation retainer, election/vote administration. Best leverage: like Trade, its revenue is a small recurring fee across EVERY other pillar's co-op — it compounds. HONESTY: governance is a HARD sell as a standalone product (people don't pay for rules until conflict hits) — see RISK. It monetizes best BUNDLED into every other co-op's setup, not sold alone. GOVERNANCE MODULE (recursive — this pillar IS the module): The governance layer governs itself with the same primitives — the facilitator is NOT the decider (No-Single-Capture: no single party controls the vote or the ledger); charter changes require supermajority; the dispute process has an appeal path; the pillar-ledger of ownership is transparent to all members. This is the reference implementation the other 12 point to. TIES: ALL 12 other pillars route their disputes, votes, and ownership records here — it's the dependency named in every other card. Twins with SECURITY (external legal defense) — internal rules + external shield are two sides of the same coin. Feeds the pillar-ledger that TRADE and every co-op uses. DO: (1) Publish the charter + voting + dispute-resolution templates from Pillar 11 (these are what every other card's \"charter stub\" points to — build them FIRST). (2) Member facilitates ONE real group charter (start with one of the other pillar's seed co-ops). (3) Set up a simple voting + dispute board for that group. (4) Run one real vote or resolve one real dispute. (5) Establish the shared pillar-ledger format.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-knowledge", "file": "WO-pillar-knowledge.md", "title": "WO-pillar-knowledge — SEEDABLE BUSINESS: offline AI + how-to library → the community's brain (Pillar 12 of 13)", "what": "WO-pillar-knowledge — SEEDABLE BUSINESS: offline AI + how-to library → the community's brain (Pillar 12 of 13)", "why": "Knowledge is how each pillar teaches the next member to start — the how-to library IS the seed-dispersal mechanism for all 13. And offline AI (the ~$75 Pi 5 stack in sovereignty-hub) means the community keeps its assistant/knowledge even when internet dies. A member can sell a configured offline-AI box + a course THIS week. Seed→scale: sell/setup offline-AI boxes + courses → a knowledge library → the AI-over-everything backbone (ties to ARAYA + the case-RAG/law-school work). SEED (~1 person): Assemble + configure Pi 5 offline-AI boxes (Whisper + Ollama + Kokoro, ~$75 parts) and sell them ready-to-run, plus a paid \"how to run your own AI\" course. Start cost = a couple Pi boxes (~$150-200). SCALE (community-critical): The community brain — a shared offline knowledge library (blueprints for all 13 pillars, case-law DB, Pattern Theory), AI assistants per household, and the training pipeline that onboards every new pillar-seed member. REVENUE (C6): SEED — a $75 offline-AI box sold configured for $180-250 (setup + curated model/knowledge pack is the value), plus a course at $30-80/head. 8 boxes + one course cohort/mo = ~$700-1200. SCALE — knowledge-library subscription ($5-15/mo — recurring), per-pillar training courses (each pillar needs onboarding content), AI-assistant hosting, the coach/LLM-course deal (existing — coach on board). Best margin: courses/content (build once, sell many); best recurring: the library subscription + the box's knowledge-pack updates. GOVERNANCE MODULE: Seed = member owns their boxes/courses. Scale = the knowledge library becomes a \"commons co-op\" node — content is open/shared per the sovereignty-hub open-source ethos (gift-economy balance — see Commander's gift-vs-paid doctrine); contributors of blueprints/courses get attribution + revenue-share credits in the pillar-ledger; what stays free vs paid is a charter decision (blueprints free, curated/live training paid); accuracy/quality disputes route to Governance. No-Single-Capture on the knowledge itself — no one owns the commons. TIES: ALL 12 other pillars need Knowledge to teach their seed (the how-to library is the onboarding for every pillar) · COMMUNICATION (AI-over-LoRa serves knowledge offline) · SECURITY (case-law DB, issue #4) · MANUFACTURING (design-file library). Knowledge is how the whole system self-replicates (3→7→13→∞ needs a teacher). DO: (1) Publish the offline-AI box BOM + \"run your own AI\" course from Pillar 12 (leverage the existing offline AI stack + issue #3 Kokoro on Pi). (2) Member assembles + configures 2 boxes, drafts the course. (3) Stand up a store + course page (Trade marketplace). (4) Sell 3 boxes or run one course cohort. (5) Log the commons-co-op charter stub + free-vs-paid clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-manufacturing", "file": "WO-pillar-manufacturing.md", "title": "WO-pillar-manufacturing — SEEDABLE BUSINESS: 3D-print/fab-on-demand → the block's factory (Pillar 7 of 13)", "what": "WO-pillar-manufacturing — SEEDABLE BUSINESS: 3D-print/fab-on-demand → the block's factory (Pillar 7 of 13)", "why": "Manufacturing is the pillar that makes the OTHER pillars' parts — filter housings, battery holders, radio mounts, replacement gears. Supply chains break; a local printer/fab shop means a broken part is a same-day fix, not a two-week wait. A single $200-400 printer + free STL files is a real business the first week. Seed→scale: print-on-demand → tool repair → a full fab shop (CNC, injection, casting). SEED (~1 person): One 3D printer running print-on-demand jobs (repair parts, custom brackets, the other pillars' components) from free/library STLs. Start cost = one printer (~$200-400). SCALE (community-critical): A community fab shop — multiple printers, CNC, casting, tool repair — that supplies replacement parts and custom builds for all 13 pillars; the member becomes the block's maker-in-chief. REVENUE (C6): SEED — print jobs priced at material + machine-time + labor: a part costing ~$1 in filament sells $8-25 depending on complexity (huge margin on labor/design). Repair jobs $15-40. 20 jobs/mo = ~$400-800. SCALE — production runs for the other pillars (filter parts, radio mounts — internal B2B), custom fabrication contracts, a design-file library subscription. Best margin: custom/design work (labor); best recurring: internal supply to the other 12 pillars + a parts subscription. GOVERNANCE MODULE: Seed = member owns their printer. Scale = a shared fab shop becomes a \"maker co-op\" node (twins with Shelter's workshop) — equipment donors get machine-time credits in the pillar ledger; a maintenance/filament fund from job margins is spent 1-member-1-vote; IP/design-ownership rules (who owns a custom design) and job-priority (survival parts first) are charter clauses; disputes route to Governance. TIES: SHELTER (shares the workshop — near-twin) · WATER/ENERGY/COMMUNICATION/MEDICINE (prints their housings, mounts, holders, device parts — Manufacturing is the parts-supplier to nearly every pillar) · KNOWLEDGE (design-file library) · TRADE (sells through marketplace). DO: (1) Publish the print-on-demand starter guide + a starter STL library from Pillar 7. (2) Member sets up one printer, runs 3 real jobs (including one part FOR another pillar). (3) Stand up an order/quote page (Trade marketplace). (4) Fill 5 neighbor jobs. (5) Log the maker-co-op charter stub + IP clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-medicine", "file": "WO-pillar-medicine.md", "title": "WO-pillar-medicine — SEEDABLE BUSINESS: herbal apothecary + first-aid readiness (Pillar 5 of 13)", "what": "WO-pillar-medicine — SEEDABLE BUSINESS: herbal apothecary + first-aid readiness (Pillar 5 of 13)", "why": "Health is survival-critical but this is the HARDEST seed to keep legal (see RISK) — you cannot diagnose/treat without licensure. The safe, real seed is wellness/topical herbal products + first-aid kit assembly + training, NOT medical care. Grown herbs (tie to Food pillar) become salves/teas/tinctures. Seed→scale: apothecary products → first-aid kits + CPR/first-aid classes → a stocked community readiness cache. SEED (~1 person): Salves, teas, tinctures from grown/foraged herbs (topical/wellness only) + assembled first-aid kits. Start cost < $150 (jars, base oils, herbs from the Food pillar). SCALE (community-critical): A stocked first-aid/readiness cache + trained responders (certified via real orgs) + telehealth-referral hub — the community's health-preparedness backbone. NOT a substitute for licensed care. REVENUE (C6): SEED — herbal salve costs ~$2-3 to make, sells $12-18 (5x); tinctures $15-30; assembled first-aid kit ~$15 cost → $35-50. First-aid/CPR class $25-50/head. 15 products + one class/mo = ~$400-700. SCALE — kit subscriptions (refresh expiring supplies, $10-15/mo recurring — consumables again), class series, readiness-cache membership. Best margin: apothecary products; best recurring: kit-refresh subscription (supplies expire → built-in repeat). GOVERNANCE MODULE: Seed = member owns their apothecary. Scale = a shared readiness cache becomes a \"health-readiness co-op\" node — the charter carries a HARD compliance clause (no medical/diagnostic claims, licensed-only for care, product-liability waiver, cottage-food/cosmetic labeling rules). Cache-stocking decisions voted 1-member-1-vote; a designated compliance steward (not majority) can veto anything that crosses into practicing medicine. Disputes route to Governance. TIES: FOOD (herbs are grown crops — direct input) · WATER (clean water prevents most illness — upstream) · KNOWLEDGE (training/guides) · ENERGY (refrigeration for meds) · SECURITY (legal/compliance overlap). DO: (1) Publish the apothecary + first-aid-kit BOM from Pillar 5 WITH the compliance clause up front. (2) Member makes a product batch (topical/wellness only) + assembles 3 kits. (3) Stand up a store/class page (Trade marketplace) with compliant labeling. (4) Sell to 5 neighbors or run one first-aid class. (5) Log the co-op charter stub + compliance clause + waiver.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-shelter", "file": "WO-pillar-shelter.md", "title": "WO-pillar-shelter — SEEDABLE BUSINESS: tool library → the block's build crew (Pillar 3 of 13)", "what": "WO-pillar-shelter — SEEDABLE BUSINESS: tool library → the block's build crew (Pillar 3 of 13)", "why": "Shelter is survival-critical #3 — a roof that fails in winter kills. Most households can't afford or store tools they use twice a year; a shared library monetizes idle tools immediately and becomes the crew that keeps everyone's shelter standing. Seed→scale: a shelf of lent tools → a workshop membership → a paid build/repair crew. SEED (~1 person): A shelf of 20-30 quality tools (drills, saws, ladders) lent by the day. Start from tools the member already owns — near-zero cash start. SCALE (community-critical): A community workshop + weatherization/repair crew that keeps roofs, insulation, and structures sound; tiny-home build support for members who need housing. REVENUE (C6): SEED — tool rental at $5-15/day/tool + a $10-20/mo library membership (unlimited borrows). 25 members = $250-500/mo recurring with tools you already own. SCALE — workshop bench-time rental ($15-25/hr), paid repair/weatherization jobs (labor $40-75/hr + materials markup), tiny-home build contracts (project-based, $2-15k). Best margin: the membership (pure recurring on sunk-cost tools); biggest ticket: build/weatherization labor at scale. GOVERNANCE MODULE: Seed = member owns the tools, sets lending rules. Scale = a shared workshop becomes a \"maker co-op\" node — tool donors get borrowing credits recorded in the pillar ledger; a tool-replacement fund is funded from membership dues, spent by 1-member-1-vote; damage/liability disputes route to the Governance dispute module (waiver clause mandatory in the charter). TIES: MANUFACTURING (workshop shares space/tools with 3D-print/fab — near-twin pillar) · ENERGY (weatherization cuts energy load) · TRADE (job booking through marketplace) · KNOWLEDGE (build guides) · TRANSPORTATION (tool/material hauling). DO: (1) Publish the tool-library starter list + lending rules from Pillar 3. (2) Member catalogs 20-30 tools, sets rental + membership price. (3) Stand up a booking/membership page (Trade marketplace). (4) Lend to 5 neighbors; enroll 2 on membership. (5) Log the maker-co-op charter stub + waiver.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-trade", "file": "WO-pillar-trade.md", "title": "WO-pillar-trade — SEEDABLE BUSINESS: the marketplace itself → the community economy (Pillar 10 of 13)", "what": "WO-pillar-trade — SEEDABLE BUSINESS: the marketplace itself → the community economy (Pillar 10 of 13)", "why": "Trade is the META-pillar — it's how every other pillar turns product into income. A community that produces water/food/energy but has no way to exchange it starves in a different way. The marketplace is the platform play: the member who runs it earns a cut of EVERY pillar's sales. Seed→scale: a listing board + monthly market day → a full local marketplace with barter credits → the community currency/economy layer. SEED (~1 person): A simple listing board (or a recurring physical market day) where the other pillars' members sell. Start cost = ~$0 (a page + a parking lot). SCALE (community-critical): The full local economy — online marketplace + barter-credit system + market days + a local unit of account (ties to the mission-tokenization/gold-back work). The member becomes the market-maker who takes a small cut of community-wide commerce. REVENUE (C6): SEED — listing/transaction fee (2-5% of each sale) OR a flat vendor fee for market-day booths ($10-25/booth). Even 10 vendors x $200 sales x 3% = modest, but it SCALES with every pillar's growth. SCALE — marketplace transaction fees across all 12 producing pillars (the affiliate/fractal cut already in the system — 20% presence cut model), premium vendor storefronts, barter-credit float, market-day sponsorships. Best margin/leverage: the platform cut — it compounds as the other 12 pillars grow. This is the pillar whose revenue is a % of ALL the others. GOVERNANCE MODULE: Seed = member operates the board. Scale = the marketplace becomes a \"commerce co-op\" node — vendors get a voice in fee structure (fee changes voted 1-member-1-vote so the market-maker can't gouge), a listed dispute/refund policy, quality/fraud standards enforced with the No-Single-Capture doctrine (no single party controls the money rail). Barter-credit issuance rules are a hard charter clause (prevent inflation). Disputes route to Governance; the fee itself is capped in the charter. TIES: ALL 12 other pillars sell through Trade (it's the common sales channel — every other card's DO step lands here) · TRANSPORTATION (moves the goods) · GOVERNANCE (fee/dispute rules) · KNOWLEDGE (reputation/reviews). Trade is the hub every spoke connects to. DO: (1) Stand up the marketplace/barter board (reuse the existing Trade marketplace + affiliate/fractal system). (2) Onboard the first 3 pillar-vendors (e.g., Water filters, Food boxes, Manufacturing prints). (3) Run one transaction end-to-end (or one market day). (4) Take the first platform fee. (5) Log the commerce-co-op charter stub + fee cap.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-transportation", "file": "WO-pillar-transportation.md", "title": "WO-pillar-transportation — SEEDABLE BUSINESS: mobile repair/diagnostics → community fleet (Pillar 9 of 13)", "what": "WO-pillar-transportation — SEEDABLE BUSINESS: mobile repair/diagnostics → community fleet (Pillar 9 of 13)", "why": "Without transport, no food/materials move and members can't get to work/court/care. A $30 OBD2 scanner reads the fault codes that dealers charge $120 to read — instant value. Mobile repair needs no shop. Seed→scale: diagnostics + basic repair → propane/alt-fuel conversion → a shared community fleet (tools, hauling, rides). SEED (~1 person): Mobile OBD2 diagnostics + basic repair (brakes, fluids, batteries) at the customer's driveway. Start cost < $200 (scanner + hand tools, often already owned). SCALE (community-critical): A shared fleet + repair co-op — pooled vehicles for hauling/rides, propane/alt-fuel conversions, and a repair shop that keeps the block's vehicles running when parts/gas get scarce. REVENUE (C6): SEED — diagnostic scan $30-60 (vs dealer $120), basic repair labor $40-75/hr + parts markup. Mobile = no shop overhead. 15 jobs/mo = ~$500-900. SCALE — fleet-share membership ($30-60/mo for pooled-vehicle access — recurring), propane-conversion jobs ($500-2000), hauling/delivery service, a parts-buying co-op. Best margin: diagnostics (labor on a cheap tool); best recurring: fleet-share membership. GOVERNANCE MODULE: Seed = member owns their tools. Scale = a shared fleet becomes a \"mobility co-op\" node — vehicle contributors get usage credits in the pillar ledger; pooled-vehicle scheduling, maintenance-fund spending, and priority-use (medical/court trips first) are charter clauses voted 1-member-1-vote; accident/liability disputes route to Governance (insurance + waiver mandatory clauses). TIES: TRADE (moves goods to market — direct dependency) · FOOD (harvest/CSA delivery) · ENERGY (EV charging, alt-fuel) · MANUFACTURING (prints/fabs repair parts) · SECURITY (rides to court). Transportation is the circulatory system between pillars. DO: (1) Publish the mobile-diagnostics starter guide + tool list from Pillar 9. (2) Member does 3 real diagnostic/repair jobs. (3) Stand up a booking page (Trade marketplace). (4) Serve 5 neighbors, note who wants fleet-share. (5) Log the mobility-co-op charter stub + insurance/waiver clauses.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-water", "file": "WO-pillar-water.md", "title": "WO-pillar-water — SEEDABLE BUSINESS: clean water as a service (Pillar 1 of 13)", "what": "WO-pillar-water — SEEDABLE BUSINESS: clean water as a service (Pillar 1 of 13)", "why": "Water is survival-critical #1 — no clean water = no community in days. The seed is the lowest-capital, fastest-to-cash pillar: a $30 bucket + filter element resells for $60-90, and everyone already needs it. Seed→scale: one filter sold this week → a filter-of-the-month + element-replacement subscription → shared rain-catch + purification for a street when the tap fails. SEED (~1 person): Build one gravity filter from the BOM (food-grade bucket + ceramic/carbon element). Sell/deliver to 5 neighbors. Total start cost < $200. SCALE (community-critical): A local water backbone — rain collection, storage, and purification that keeps a block alive through an outage; the member becomes the \"water keeper\" with recurring element supply. REVENUE (C6): SEED — unit sale, ~$30 cost → $60-90 price (2-3x markup), plus $8-12/mo element-replacement subscription per household (elements need swapping every 3-6 mo → recurring by design). SCALE — shared-system install fee ($200-800 per block) + ongoing purification/testing service ($15-25/household/mo). 10 households on element subs = ~$100/mo passive at seed; a serviced block = $200-400/mo. Highest margin: the recurring element sub, because it's a consumable. GOVERNANCE MODULE: Charter template from Pillar 11 (Governance). Seed = sole-proprietor member owns their kit. Scale = when a shared system serves >3 households, it converts to a \"water co-op\" node — households buying in get 1 vote each on maintenance-fund spending; disputes (quality, billing) route to the community dispute-resolution module. Ownership recorded in the pillar ledger; the keeper is paid a service wage, not rent-seeking. TIES: ENERGY (pumps/UV purification need power) · MEDICINE (waterborne-illness prevention is the #1 health lever) · GOVERNANCE (co-op charter + disputes) · KNOWLEDGE (BOM/build docs) · TRADE (sells through the marketplace). DO: (1) Publish the water micro-utility BOM + build video from sovereignty-hub Pillar 1. (2) Stand up a one-page order form (Trade pillar marketplace) with unit price + element subscription tier. (3) Member builds ONE filter, sells to 5 households, enrolls at least 2 on element subs. (4) Log the co-op charter stub even at seed (owner = the member).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-poster-prompting-system", "file": "WO-poster-prompting-system.md", "title": "WO — Poster Prompting System (find the proven method, so we make GREAT posters not junk)", "what": "WO — Poster Prompting System (find the proven method, so we make GREAT posters not junk)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pr3-bus-command-center", "file": "WO-pr3-bus-command-center.md", "title": "WO-pr3-bus-command-center — Operation Bus Command Center: capture + build spec", "what": "WO-pr3-bus-command-center — Operation Bus Command Center: capture + build spec", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-rail-sectioning", "file": "WO-rail-sectioning.md", "title": "fix the 17-widget business-rail squish (section it, or add business sub-modes)", "what": "S410 loaded the full approved cockpit onto KORPAKS.business — 17 ids on ONE flat rail: leads,orders,booking,revenue,comms,messages,calls,contacts,case,caseboard,casetimeline,todos, projects,agents,calendar,earn,page. It works, but it's dense — the exact \"16-widget squish\" S377 warned about, now real on mobile width.", "why": "A rail you have to hunt through isn't a cockpit. The loadout is RIGHT (Commander-approved); the PRESENTATION needs a pass so money/comms/case/build read as groups, not a wall of icons. DO: Pick ONE with Commander (mockup both): (A) SECTION THE RAIL — group headers (💰 Money · 💬 Comms · ⚖️ Case · 🛠️ Build · ⚙️ Utility) in the rail panel. Least disruptive; KORPAKS stays one array, buildRail() renders dividers. (B) BUSINESS SUB-MODES — the mode-dial gains a second ring inside \"business\" (money/comms/case/ build); each sub-mode filters the rail. More powerful, bigger change.", "where": "my/pulse.html — buildRail() (~line 4744), KORPAKS.business (~line 1123), CRChromeV2.setRail(). RAIL_SHORT labels + the curate sheet (renderCurate) may need matching group metadata.", "who": "A Claude window + Commander eyeball (this is a UX call, not a mechanical fix)", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "★ THE WHOLE THING", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-reception-operator-console-repoint", "file": "WO-reception-operator-console-repoint.md", "title": "WO-reception-operator-console-repoint — reception door opens the OPERATOR console, not the sales page", "what": "WO-reception-operator-console-repoint — reception door opens the OPERATOR console, not the sales page", "why": "Wave-3 batch-2 comb (reception C2/C3/C8, money_weight 9) — the reception door is wired to the WRONG canonical. The registered door (my/pulse.html:1195 url:/receptionist.html) opens a 13-section SALES FUNNEL that sells the receptionist to an owner who already owns it; the registry's OWN mission demands an OPERATOR console (\"watch/run MY receptionist: line status, calls caught, 5-W summaries\"). That console ALREADY EXISTS: receptionist-log.html (\"THE LOG\", P1 of DNA/RECEPTIONIST_UX_BLUEPRINT.md, backed by netlify/functions/receptionist-api.mjs) — but it's an ORPHAN (0 inbound HTML links). One widget, two files, door on the wrong one. This is the root of the registry's top work_order for reception. ⚠ PRODUCT DECISION: Commander approved doing this \"next\" (S442) — repointing changes what every business user sees on the reception tile (sales page → their live call log). DO: - Repoint the reception door url (pulse KORPAK_DOORS ~L1195 + the araya-chat door if separate ~:9504) to receptionist-log.html. Verify the operator console loads in the page-door + reads receptionist-api. - Rehome the SALES page (receptionist.html): give it its own sales/L2 door or a marketing route, so the sell-flow isn't lost — it just stops being what an OWNER sees on their own tile. - Wire receptionist-log.html into the registry/inventory (it's currently an orphan) so it stops being one. - Fix the operator surface's card: show live call/lead telemetry (calls caught, line status, minutes) not the static \"tap to open\" placeholder — pairs with WO-ar-receipt-floor + the reception D1 finding.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-reland-s448-code-seams", "file": "WO-reland-s448-code-seams.md", "title": "WO-reland-s448-code-seams — hand-reconcile the code seams of the closed S446-S448 branches", "what": "WO-reland-s448-code-seams — hand-reconcile the code seams of the closed S446-S448 branches", "why": "the stacked S446-S448 branches were closed S453 (merge-captain clearing wave) because their tree lagged everything merged since — a bulk merge would REVERT the identity floor (#1265), XP seals, and chrome standard. Pure additions landed via PR #1267; these seams are the remainder.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-repair-ollama-llama-server", "file": "WO-repair-ollama-llama-server.md", "title": "WO-repair-ollama-llama-server — Repair ollama inference engine (llama-server binary missing) — unblocks the whole free fleet", "what": "WO-repair-ollama-llama-server — Repair ollama inference engine (llama-server binary missing) — unblocks the whole free fleet", "why": "THE fleet blocker (S420, proven live): ollama 0.32.5 api/tags works but every /api/generate fails install-wide with 'llama-server binary not found' — so no local model can generate and the free crew can complete zero code WOs. The WO pipe itself is now fixed and proven; this inference engine is the only wall left. DO: Repair the ollama install so llama-server exists: reinstall/upgrade ollama (the installer bundles the runner) or rebuild the runner; then test qwen2.5-coder:7b and qwen3-coder:30b generate.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-route-git-email-to-100xbuilder", "file": "WO-route-git-email-to-100xbuilder.md", "title": "GitHub email to @100xbuilder.io addresses is failing — fix the inbound routing", "what": "Mail SENT TO @100xbuilder.io addresses (GitHub notifications / verification / invite emails to the git identities like opencode-33@100xbuilder.io) has been FAILING ALL DAY (Commander report, 2026-08-06). Restore inbound email routing so those messages land in an inbox the system actually reads.", "why": "The 100X_DEPLOYMENT git author identity is `opencode-33@100xbuilder.io` (and other opencode-NN@ 100xbuilder.io seats). GitHub sends verification/notification/invite email to those addresses. The existing email pipeline (email_to_case / gmail_sweep) only reads GMAIL accounts (primary + kulture, status OK 15:30). If @100xbuilder.io has no working MX / forwarding into one of those Gmail inboxes, every GitHub email to the domain bounces or black-holes — which blocks git invites, verification, and notifications. This is DNS/provider config (outside the repo), so it needs Commander's domain access.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-seller-onboarding-cart-funnel", "file": "WO-seller-onboarding-cart-funnel.md", "title": "WO-seller-onboarding-cart-funnel — Cart-simple funnel to start selling on ARAYA OS", "what": "WO-seller-onboarding-cart-funnel — Cart-simple funnel to start selling on ARAYA OS", "why": "Selling on ARAYA OS today is scattered across offerings, pages, pricing, and Stripe with no single on-ramp — the friction kills the first sale. A cart-simple, one-path funnel lets any builder list a thing and walk away with a working \"Buy\" link without knowing where anything lives. This is the money on-ramp for the presence-FREE + 20%-cut + $29-hosting model. DO: Build a guided seller funnel that feels like an e-commerce checkout: audit existing pieces first, then a short stepper (what → details → price → payout → publish) that ends in a live, shareable buy link. See RING 3 for the steps.", "where": "The ONE shell (build INTO my/pulse.html, never a standalone page); reuse existing Stripe/offerings/checkout functions for the buyer side.", "who": "Seller-facing, gated to any signed-in builder; payout gated behind Stripe connect. Unclaimed. SPAWN: if it lands — a matching BUYER cart-polish card + an affiliate/XP share-loop card. RELATED: project_offerings-consolidation, project_seven-doors-first-sale, project_builder-onboarding-funnel, project_creator-tools-platform-vision, project_recursive-products-strategy, TIER_AND_AUTOBUILD_MAP_S384, project_mission-tokenization-funding SOURCE: Commander dictation S426 — \"onboarding funnel for selling on araya os, has to be easy like a shopping cart.\"", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-settings-menu-upgrades", "file": "WO-settings-menu-upgrades.md", "title": "WO-settings-menu-upgrades — line up the settings menu (Commander highlighted it)", "what": "WO-settings-menu-upgrades — line up the settings menu (Commander highlighted it)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-shirts-store-revive", "file": "WO-shirts-store-revive.md", "title": "WO — Shirts Store Revive (fastest money: product exists, store is broken)", "what": "WO — Shirts Store Revive (fastest money: product exists, store is broken)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-sign-bug-attachment-display", "file": "WO-sign-bug-attachment-display.md", "title": "WO-sign-bug-attachment-display — Render bug screenshots via signed URLs (bucket is now private)", "what": "WO-sign-bug-attachment-display — Render bug screenshots via signed URLs (bucket is now private)", "why": "S425 security closed the world-readable bug-attachments bucket (flipped private + upload returns a 7-day signed URL). But OLD bug rows store /object/public/bug-attachments/ URLs that now 404, and the redaction path scrubs them for non-Commander. The Commander's board no longer renders historical screenshots until they're re-signed on read. ENABLES: bug triage keeps working with screenshots, with zero world-readable exposure. DO: In tasks-api handleList (the isCommander branch), detect any /object/(public/)?bug-attachments/ or /object/(public/)?vault/ URL in a row's description/fields, extract , mint a short-lived signed URL (POST /storage/v1/object/sign//), and replace it. Apply the same on the bug-detail view if it reads elsewhere. Keep non-Commander scrubbed (no leak).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-signal-forge-music-define", "file": "WO-signal-forge-music-define.md", "title": "WO-signal-forge-music-define — DEFINE: Signal Forge (music)", "what": "WO-signal-forge-music-define — DEFINE: Signal Forge (music)", "why": "North-Star chunk: Signal Forge (music). A fun music-making area: people make songs, bring them back to their Command, and attach them to their vault projects. Lay out the Signal Forge blueprints. ENABLES: completing this turns 'Signal Forge (music)' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/signal-forge-music.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-signal-forge-music", "file": "WO-signal-forge-music.md", "title": "WO-signal-forge-music — make the Signal Forge a place people MAKE MUSIC (blue/741Hz — /signal.html)", "what": "Signal Forge (blue, 741Hz) becomes a music-making hub — people generate/compose music there. REUSE what exists: widget-music.js, the music-generation-pipeline (ElevenLabs, songs-table + player), WO-magical-music-dashboard. ADD a music-gen API tie-in (Suno/ElevenLabs/similar — market-grep first) so a visitor types a vibe → gets a track. Ability-first: it DOES (makes music), not just displays.", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-signup-password-not-persisted", "file": "WO-signup-password-not-persisted.md", "title": "WO — Signup password doesn't authenticate later (auth-door bug #3)", "what": "WO — Signup password doesn't authenticate later (auth-door bug #3)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-slice3b-relink-docs-conversations", "file": "WO-slice3b-relink-docs-conversations.md", "title": "WO-slice3b-relink-docs-conversations — resolver-then-relink for documents/conversations/chat", "what": "WO-slice3b-relink-docs-conversations — resolver-then-relink for documents/conversations/chat", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-speaking-tour-onboarding-define", "file": "WO-speaking-tour-onboarding-define.md", "title": "WO-speaking-tour-onboarding-define — DEFINE: Speaking Tour & Onboarding", "what": "WO-speaking-tour-onboarding-define — DEFINE: Speaking Tour & Onboarding", "why": "North-Star chunk: Speaking Tour & Onboarding. Commander travels — podcasts, YouTube, meeting groups, demoing ARAYA. Needs cards, shirts, a printed itinerary of what he speaks about, and a full onboarding flow of what he shows. ENABLES: completing this turns 'Speaking Tour & Onboarding' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/speaking-tour-onboarding.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-state-adopt-setup-gate", "file": "WO-state-adopt-setup-gate.md", "title": "WO-state-adopt-setup-gate — move the onboarding flag off localStorage onto the state spine", "what": "WO-state-adopt-setup-gate — move the onboarding flag off localStorage onto the state spine", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-store-pattern-clone", "file": "WO-store-pattern-clone.md", "title": "WO-store-pattern-clone — ONE storefront engine, three tenants (Commander · Tiger · Johnny)", "what": "WO-store-pattern-clone — ONE storefront engine, three tenants (Commander · Tiger · Johnny)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-succession-cockpit-future-blueprint", "file": "WO-succession-cockpit-future-blueprint.md", "title": "WO-succession-cockpit-future-blueprint — the \"throw the laptop away\" round: run without Commander + boot the future-story from all the data", "what": "WO-succession-cockpit-future-blueprint — the \"throw the laptop away\" round: run without Commander + boot the future-story from all the data", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-t11-pilot-closer-loop", "file": "WO-t11-pilot-closer-loop.md", "title": "WO-t11-pilot-closer-loop — 5-card pilot: prove the CLOSER loop, with pulse", "what": "WO-t11-pilot-closer-loop — 5-card pilot: prove the CLOSER loop, with pulse", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tablet-missing-business-slider", "file": "WO-tablet-missing-business-slider.md", "title": "WO-tablet-missing-business-slider: 3rd cockpit slider (\"My Business\") flashes then vanishes on tablet — hardcoded single-gmail gate rejects the tablet's signed-in identity", "what": "WO-tablet-missing-business-slider: 3rd cockpit slider (\"My Business\") flashes then vanishes on tablet — hardcoded single-gmail gate rejects the tablet's signed-in identity", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-talking-stuffed-animals-kit", "file": "WO-talking-stuffed-animals-kit.md", "title": "Pi Zero → Bluetooth → stuffed animal that talks (Amelia's Explorer Kit) STATUS: open LANE: SOMEDAY-BUT-LIVE", "what": "Pi Zero → Bluetooth → stuffed animal that talks (Amelia's Explorer Kit) STATUS: open LANE: SOMEDAY-BUT-LIVE", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "SOMEDAY-BUT-LIVE", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-the-device-store-gadgets-define", "file": "WO-the-device-store-gadgets-define.md", "title": "WO-the-device-store-gadgets-define — DEFINE: The Device Store (gadgets)", "what": "WO-the-device-store-gadgets-define — DEFINE: The Device Store (gadgets)", "why": "North-Star chunk: The Device Store (gadgets). Collect every builder device in one store — cyber decks, handhelds. Decide: become a wholesale provider for everyone, and/or make our own. Vendors give devices to test free in exch ENABLES: completing this turns 'The Device Store (gadgets)' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/the-device-store-gadgets.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-tier-naming-office-manager-to-operation", "file": "WO-tier-naming-office-manager-to-operation.md", "title": "align L3 backend name to \"The Operation\" STATUS: open LANE: NEXT", "what": "align L3 backend name to \"The Operation\" STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tiger-tax-liens-araya-memory", "file": "WO-tiger-tax-liens-araya-memory.md", "title": "WO-tiger-tax-liens-araya-memory: (PARKED) — do NOT ingest Tiger's software; his lien docs are just files", "what": "WO-tiger-tax-liens-araya-memory: (PARKED) — do NOT ingest Tiger's software; his lien docs are just files", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-trademark-preble-painting-serial", "file": "WO-trademark-preble-painting-serial.md", "title": "PREBLE PAINTING — find the serial number (5th mark, classes 009/037/042) STATUS: open LANE: NEXT", "what": "PREBLE PAINTING — find the serial number (5th mark, classes 009/037/042) STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "B3 Compliance Master (Trademark", "priority": "P2", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trello-audience-gated-wo-board", "file": "WO-trello-audience-gated-wo-board.md", "title": "WO-trello-audience-gated-wo-board — Wrangle ALL todo/kanban/WO surfaces into ONE Trello/Kanban (one store · one board · N pivots)", "what": "WO-trello-audience-gated-wo-board — Wrangle ALL todo/kanban/WO surfaces into ONE Trello/Kanban (one store · one board · N pivots)", "why": "Task tracking is fragmented across ~2 data stores + 6 widgets + a page + a dozen TODO files: dev_board_tasks (SQL via tasks-api) backs dev-board.html; WORK_ORDERS_BOARD.json (generated from WO .md files) backs widget-workdesk/widget-wo-board; plus widget-board, widget-tasks2, widget-todos, widget-caseboard and MASTER_TODO/TODO/COMMANDER_TODO/etc. The prior-art study BOARD_UX_PRIOR_ART.md (S395) already set the law — \"ONE store, ONE widget, N pivots; never fork the board per audience\" — it just hasn't been executed. This card executes it: unify the stores, make ONE board with group-by pivots (list/status/who) and an audience gate, and retire the rest. DO: Converge the two stores into one feed, extend widget-workdesk into the single Trello/Kanban with a group-by pivot + audience gate (reuse the S426 access_level ladder), and turn every other board surface into a view/redirect. See RING 3.", "where": "Build INTO the ONE shell (widget-workdesk in pulse); reuse todo-claims-api for claim/complete and Auth.getAccessLevel()/meetsAccess() from the S426 scaffold. No new board, no new store.", "who": "COMMANDER-authored; the board is multi-audience by construction (public columns public; dev/commander columns gated). Unclaimed. SPAWN: store-convergence card (reconcile dev_board_tasks ↔ WORK_ORDERS_BOARD.json), drag-between-columns (= field mutation), retire-duplicate-widgets card, per-list share links. RELATED: BOARD_UX_PRIOR_ART.md, ONE_INTERFACE_MASTER_PLAN_S369.md, project_permission-ladder, project_rolling-todo-system, project_one-cockpit-confluence, project_multiplayer-agent-cockpit, WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, WO-guardian-forge-opensource-tools, WO-health-detox-frequency-tek-marketplace SOURCE: Commander dictation S426 — \"the WO board needs to be like Trello, different columns viewable to different audiences, ~10 WO lists... we need to wrangle in all the todo/kanban/WO system — it can all be turned into a kanban/trello situation.\" (Existing kanban acknowledged: dev-board.html + widget-workdesk.)", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-trinity-dev-widget", "file": "WO-trinity-dev-widget.md", "title": "WO-trinity-dev-widget — In-shell Trinity widget for developers (project start/finish rail)", "what": "ONE widget inside the Pulse shell (ONE-Shell law — no new page, no new surface) that puts the Trinity (C1 Mechanic · C2 Architect · C3 Oracle) in front of a developer at the two moments it matters: - PROJECT START: cascade-style forced planning — the trinity reads the project brief and returns build/design/foresee angles before code is written. - PROJECT END: close-out — verify/receipts/debrief prompts before the PR/hand-off.", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tune-file-add-ux", "file": "WO-tune-file-add-ux.md", "title": "WO — Tune the File-Add UX (study real file systems, add 5 missing traits)", "what": "WO — Tune the File-Add UX (study real file systems, add 5 missing traits)", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-usage-telemetry-clobber", "file": "WO-usage-telemetry-clobber.md", "title": "WO-usage-telemetry-clobber — nightly usage_7d stamps get clobbered by stale-base registry commits (systemic)", "what": "WO-usage-telemetry-clobber — nightly usage_7d stamps get clobbered by stale-base registry commits (systemic)", "why": "Wave-3 comb (S442) C5-telemetry found the SAME root on 8 widgets: PULSE_WIDGET_REGISTRY usage_7d is stale/missing. 19/51 widgets have NO usage_7d at all; the 32 that do are frozen at usage_asof=2026-08-07, while the nightly rollup's own receipt is fresh (usage_latest.json, Aug 15, e.g. calls=8, contacts=13). Real usage lives in analytics_events and the rollup computes it correctly — but registry commits from a STALE BASE overwrite the local-only rollup stamps (USAGE_ROLLUP.py:112-136 stamps working-tree only; the next registry rewrite clobbers it). = the \"gauge mismeasures, fleet is fine\" pattern (project_custom-cockpits-engine). Signal captured then lost at the registry. Every widget's C5/D3 grade is capped at C until this is fixed. DO: - Decide the durable path: either (a) rollup writes usage_7d to a SEPARATE published data file (my/appdash/usage.json) that the gauge reads, NOT into the hand-edited registry (stop the clobber by separating machine-stamped telemetry from hand-curated rows); or (b) rollup commits its own stamps on a schedule and registry edits rebase onto them. - Prefer (a): telemetry is machine data, the registry is a curated catalog — they should not share a file that two writers fight over. Pairs with the WIDGET_LEDGER gauge-mismeasure note. - Backfill the 19 missing widgets once the durable path exists.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-vault-ungate-previewer", "file": "WO-vault-ungate-previewer.md", "title": "WO-vault-ungate-previewer — the on-interface vault previewer works for real users, not just Commander", "what": "WO-vault-ungate-previewer — the on-interface vault previewer works for real users, not just Commander", "why": "widget-canvas (the vault \"Work Area\" / document-preview surface on the pulse cockpit) reads `/.netlify/functions/commander-vault-feed?action=list`, which returns 401 to every non-Commander (commander-vault-feed.mjs guards Commander-only). So a seated builder who logs into the cockpit sees an EMPTY vault + no preview. Meanwhile `vault-api.mjs ?action=list` already lists vault_items scoped to the caller's verified identifiers (email AND uuid) — multi-user and identity-safe. Point the widget at vault-api so the vault works for everyone. This is the #1 vault fix (VAULT_DASHBOARD_FINAL_DESIGN_S426 §4). DO: In components/widgets/widget-canvas.js, change the list feed source from `/.netlify/functions/commander-vault-feed?action=list` to `/.netlify/functions/vault-api?action=list` (keep the `Authorization: Bearer` JWT header). vault-api returns `{ items: [...] }` (rows from vault_items: title, file_url, mime_type, created_at, room, tags) — map those to the card's existing render fields; if commander-vault-feed used `documents`, adapt the field names. Do NOT modify commander-vault-feed.mjs or vault-api.mjs.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-video-in-main-chat", "file": "WO-video-in-main-chat.md", "title": "WO-video-in-main-chat — LiveKit video calls INSIDE Main Chat rooms", "what": "WO-video-in-main-chat — LiveKit video calls INSIDE Main Chat rooms", "why": "PR #1096 (S424, closed S453 by merge-captain triage) built a standalone /video-room.html with a ONE-GATE LiveKit token server — solid code, wrong door: the S436 one-chat consolidation law says any new room/call surface must be born INSIDE Main Chat, never as a new page. LiveKit never landed anywhere else, so the capability is still wanted. SALVAGE: closed PR #1096 (branch opencode-122-livekit-room preserved) — reuse `livekit-token.mjs` (token server with access_level>=7 host controls) nearly as-is; the room UI must be rebuilt as a Main Chat room feature, not ported.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-view-01-gate", "file": "WO-view-01-gate.md", "title": "WO-view-01-gate — Front Door + Identity as ONE entry view (Gate)", "what": "WO-view-01-gate — Front Door + Identity as ONE entry view (Gate)", "why": "One of the locked 6 views. Front Door (explain+enter) and Identity (authenticate+permissions) are one funnel; keep them a single Gate lens. Provider login (GitHub/Google) already exists — don't rebuild. DO: Screenshot current -> VIEW_SLOTS/current/01-gate.png. Clean SaaS landing -> Enter/Log In -> Forge Passport auth -> lands in Home (Pulse). Blueprint-card: every button->destination, data=profiles+access_level. Borrow SaaS-landing + Supabase-Auth patterns. Re-shoot into slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-02-home", "file": "WO-view-02-home.md", "title": "WO-view-02-home — Home / \"what needs attention\" (Pulse V2)", "what": "WO-view-02-home — Home / \"what needs attention\" (Pulse V2)", "why": "One of the locked 6 views. The \"what the hell is happening right now\" screen: my work / team / attention / recent. It is the OS-desktop lens over the one task graph, NOT another board. DO: Screenshot current -> VIEW_SLOTS/current/02-home.png. Blueprint-card: MY WORK (assigned/awaiting/ blocked) · TEAM · ATTENTION (build/PR/blocked) · RECENT activity — all read from dev_board_tasks + spine. Every tile deep-links to the task. Upgrade to BUILDER_STANDARD. Re-shoot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-03-chat-redo", "file": "WO-view-03-chat-redo.md", "title": "WO-view-03-chat-redo — Guild Home / MAIN CHAT is real bad, full redo (P0)", "what": "WO-view-03-chat-redo — Guild Home / MAIN CHAT is real bad, full redo (P0)", "why": "Commander sent Toasted a link; thumbnail says \"Case Builder\", opens a public view where anyone can watch the conversation, and the chat is \"terrible looking / demented / real bad\". This is view 03 (Guild Home) — the lobby + first impression. It shames the whole guild. Redo the whole thing. DO: Screenshot current (proof of before). Redesign the chat surface to Discord/Slack quality: clean room rail (permission-based rooms: Build Guild/Case Builder/Builder Revolution), readable message thread, composer, presence. Fix the shareable public-conversation view (the \"anybody can watch\" link) so it looks intentional, not broken. Match BUILDER_STANDARD. Borrow proven room/thread UX, don't invent.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-04-command-center", "file": "WO-view-04-command-center.md", "title": "WO-view-04-command-center — upgrade the Command Center view to its blueprint-card", "what": "WO-view-04-command-center — upgrade the Command Center view to its blueprint-card", "why": "One of the 7 locked Build Guild views. Must match its blueprint-card and borrow the proven pattern (Trello + Linear) instead of inventing navigation. It is a LENS on the one task/object graph, not a separate app. DO: Screenshot current -> VIEW_SLOTS/current/04-command-center.png. the WO Kanban; columns Backlog/Ready/Active/Review/QA/Done + Blocked state; card=the task; Grab -> Workbench. Write/confirm its blueprint-card (purpose·model·every button->destination·data object). Upgrade to BUILDER_STANDARD. Re-shoot into the slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-05-workbench", "file": "WO-view-05-workbench.md", "title": "WO-view-05-workbench — upgrade the Workbench view to its blueprint-card", "what": "WO-view-05-workbench — upgrade the Workbench view to its blueprint-card", "why": "One of the 7 locked Build Guild views. Must match its blueprint-card and borrow the proven pattern (GitHub + IDE/Codespaces) instead of inventing navigation. It is a LENS on the one task/object graph, not a separate app. DO: Screenshot current -> VIEW_SLOTS/current/05-workbench.png. THE GAP: per-task workspace (requirements+files+code+contextual ARAYA+chat); Submit Review -> view 06; this is the one real build. Write/confirm its blueprint-card (purpose·model·every button->destination·data object). Upgrade to BUILDER_STANDARD. Re-shoot into the slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-06-knowledge-ship", "file": "WO-view-06-knowledge-ship.md", "title": "WO-view-06-knowledge-ship — Knowledge / Ship (releases + docs + deploy)", "what": "WO-view-06-knowledge-ship — Knowledge / Ship (releases + docs + deploy)", "why": "One of the locked 6 views. Releases, documentation, tutorials, completed projects; Ship = deploy. DO: Screenshot current -> VIEW_SLOTS/current/06-knowledge-ship.png. Blueprint-card: releases·docs· tutorials·build-logs·completed-projects; Ship button = bash DEPLOY.sh (NEVER bare netlify). Borrow Notion + GitHub Releases. Re-shoot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-voice-action-tools", "file": "WO-voice-action-tools.md", "title": "wire ARAYA's action-tools into the VOICE path (run the business by talking to the phone) STATUS: open LANE: FRONTIER", "what": "wire ARAYA's action-tools into the VOICE path (run the business by talking to the phone) STATUS: open LANE: FRONTIER", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "FRONTIER", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-voice-text-fallback", "file": "WO-voice-text-fallback.md", "title": "WO-voice-text-fallback — Add a text-input fallback to araya-voice.html (POSTs to the real araya-chat function)", "what": "local model edit via aider", "why": "Voice-only excludes anyone who can't/won't talk (Bill Varney lane). S420 a free unit tried this and hallucinated a fake /send-text endpoint; this card is self-contained with the REAL code. DO: In araya-voice.html make exactly two insertions, changing nothing else.", "where": "aider edited: araya-voice.html (working tree, uncommitted — review/promote)", "who": "aider-local", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-widget-contract-fleet-sweep", "file": "WO-widget-contract-fleet-sweep.md", "title": "WO-widget-contract-fleet-sweep — full-fleet widget-contract check (missing mount() = phantom orphans)", "what": "WO-widget-contract-fleet-sweep — full-fleet widget-contract check (missing mount() = phantom orphans)", "why": "S442 Phase-1 fixer (PR #1220) found widget-vault.js was missing its required `mount()` — documented in the file's contract but never implemented — so the shell could never mount it. THIS is why the comb flagged vault as a never-loading orphan while the registry stamped it LIVE. The Widget Contract Lint only runs on CHANGED files, so an unknown number of unmodified widgets have the same silent missing-mount (or other contract) gap — each one a widget the registry calls LIVE that no shell can actually render. The ledger already lists 5 orphans (widget-green-projects/maps/news-reader/vault/voice); vault's root was a missing mount, so the others deserve the same check. DO: - Run the Widget Contract Lint over the whole components/widgets/ fleet once; list every widget missing a required contract method (mount/renderCard/renderExpanded/unmount) or exports. - For each real widget (not a to-be-retired orphan), add the minimal honest method (mirror a sibling, as vault's mount delegated to renderExpanded). For genuine orphans, hand to WO-widget-dedupe. - Pairs with WO-registry-verdict-integrity: a widget missing mount() must NOT be stamped verdict:LIVE.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-dedupe-calls-comms-cluster", "file": "WO-widget-dedupe-calls-comms-cluster.md", "title": "WO-widget-dedupe-calls-comms-cluster — one calls/comms surface, one registry row (de-dupe)", "what": "WO-widget-dedupe-calls-comms-cluster — one calls/comms surface, one registry row (de-dupe)", "why": "Wave-3 comb (S442) C2-split found on `calls`: 1. RIVAL CANONICAL CLAIM — components/widgets/widget-news-reader.js declares it \"Replaces widget-calls.js + widget-messages.js + widget-email.js + widget-dm.js + widget-comms.js\" and calls itself \"the ONE canonical comms surface\" (S415) — but it is an ORPHAN: mounted by zero HTML, absent from PULSE_WIDGET_REGISTRY, only in WIDGET_LEDGER.csv row 37 loaded=False. Two files each claim to be THE calls surface; widget-calls.js is the one actually shipped. 2. LIVE ORG-CHART CONFLICT — DNA/ORG_CHART.json carries TWO name_collision rows for one object: node 474 'widget-calls' (kind=widget, RoR=WIDGET_LEDGER.csv) + node 558 'M-ec5301' \"Calls\" (kind=module, RoR=MODULE_REGISTRY.json, path pulse.html?open=calls). Same widget, two IDs, two registries of record. Confirmed live on prod. DO: - Decide canonical: widget-calls.js is shipped → either DELETE the orphan widget-news-reader.js (reversible; it loads nowhere) or downgrade its header claim so it stops claiming to be THE comms surface. Same for the other 4 it claims to replace (messages/email/dm/comms) — verify each is or isn't actually superseded before touching. - Collapse the org-chart double-track: one object = one row. Pick the RoR (widget → WIDGET_LEDGER or the unified MASTER_REGISTRY) and make the module row (M-ec5301) an alias/pointer, not a second object. This is the exact \"165 conflicts\" de-dupe the org chart was built to drive. - Re-run the org-chart generator; the two name_collision flags for calls must clear.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-split-program", "file": "WO-widget-split-program.md", "title": "WO-widget-split-program — The split program — 22 oversized widgets down to crew size, one per card", "what": "WO-widget-split-program — The split program — 22 oversized widgets down to crew size, one per card", "why": "Ledger S420b: 22 widgets exceed the 400L crew ceiling (worst: planner 942, leads2 938, canvas 928). Every split converts a manager-only file into crew territory — the compounding unlock for the North Star. ENABLES: once done, builders + users get widget split program working in-shell — it unlocks that capability on the board (what completing it allows). DO: Manager-lane program: per widget, extract views/data helpers into widget-X-views.js keeping the contract file under 400L; one widget per session max; regenerate the ledger after each as the receipt; start with widget-comms (843L, comms is a live business lane).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-widget-wiring-view", "file": "WO-widget-wiring-view.md", "title": "WO-widget-wiring-view — read-only wiring-graph EXPLAIN view from the registries", "what": "WO-widget-wiring-view — read-only wiring-graph EXPLAIN view from the registries", "why": "PR #941 (S417, closed S453 by merge-captain triage) built site/widget-flow.html — an n8n-style visual canvas — but the branch was 36 files of tangled S417 sprawl around that one deliverable, and a standalone editor page violates ONE-shell + the registries are now the single source of truth (WIDGET_FACTORY.md). The small, still-wanted kernel is the read-only EXPLAIN view generated from the registries. SALVAGE: branch opencode-56/widget-flow-editor preserved — site/widget-flow.html's render code is reference-only; rebuild as a view, generated, read-only.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-woboard-kill-merge", "file": "WO-woboard-kill-merge.md", "title": "WO-woboard-kill-merge — retire woboard into workdesk (duplicate, no sellable tier)", "what": "WO-woboard-kill-merge — retire woboard into workdesk (duplicate, no sellable tier)", "why": "Wave-3 batch-3 comb + critic — woboard scored HEALTH 68 (every dimension C/D) and was being combed as a fixable widget, BUT its own C6-wealth lens says it is on NO sellable tier and it duplicates the work-order/board surface that workdesk (id 'workdesk', S426) already owns as the superset (BOARD view = unified board-feed). \"BOARD-CLUSTER TRIPLICATION\" — three script-loaded widgets cover the same board. Fixing woboard is wasted effort; the move is to retire it, not repair it. STOP combing it as fixable. DO: confirm workdesk covers woboard's function; retire woboard (unregister from shell, mark orphan/retired in registry, or redirect its door to workdesk); fold any unique woboard capability into workdesk first. Pairs with the board-cluster de-dupe (workdesk C2-split) + WO-widget-dedupe.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-xp-award-hardening-round2", "file": "WO-xp-award-hardening-round2.md", "title": "the remaining xp-award security debts STATUS: open LANE: NEXT", "what": "the remaining xp-award security debts STATUS: open LANE: NEXT", "why": "#1234 sealed the unlimited-mint hole and #1239 caps repeat-farming, but adversarial review (C9, 2 rounds) filed four residual debts. They're not blockers for the loop going live, but they should land before XP gates anything of value (WO-xp-room-unlock depends on the first one).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-xp-room-unlock", "file": "WO-xp-room-unlock.md", "title": "crossing an XP floor unlocks a room (the promotion mechanic) STATUS: open LANE: NEXT", "what": "crossing an XP floor unlocks a room (the promotion mechanic) STATUS: open LANE: NEXT", "why": "The reward loop pays XP and now shows it (HUD, #1238), but XP doesn't yet UNLOCK anything — \"cross a floor → a room opens\" is the payoff that makes leveling matter. Investigated S449: rooms (rooms-api.mjs) are MEMBERSHIP/invite-based, NOT gated by xp or access_level. So this is net-new, and HOW it's wired matters for security.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false } ] }, "routed": { "DEVELOPER": [ { "id": "WO-agent-router", "file": "WO-agent-router.md", "title": "route a Work Order to the participant most likely to finish it, and measure whether the routing was right", "what": "A router that takes an incoming Work Order and picks who runs it — which agent, which model, which human, or which chain of them — using required skills, cost, latency and PAST MEASURED PERFORMANCE on similar cards. Then it records whether that choice worked, so the next routing decision is better than the last.", "why": "REASON: raised in the S446 architecture pass as the way 50 disconnected AI systems become one workforce instead of 50 assistants. PROBLEM: routing today is by hand and by lane. A card is stamped MACHINE-1/2/3 by whoever wrote it, based on a guess about difficulty, and nothing ever checks whether that guess was right. We have real evidence the guesses are wrong at scale: the board carries 178 UNLANED cards, and a parse bug in S445 had 33 more cards silently unrouted despite declaring a lane. Nobody is measuring which agent or model actually completes which class of work, so we cannot get better at assigning it. UNLOCKS: honest agent grades (which model finishes which card class), cost control (stop sending cheap cards to expensive models), and the first real input to an AI creator economy — an agent's reputation becomes earned rather than claimed.", "where": "repo: overkor-tek/consciousness-revolution files to read FIRST: 100X_DEPLOYMENT/DNA/AGENT_ENTRY.md (how an agent claims work today) · the cloud_queue create() path added S444 (the sanctioned CP3 route for pushing backlog into claimable cards) · Desktop/1_COMMAND/WORK_ORDERS/parse_wo.py (TIER / TRANSPORT / cloud_ready — the existing hand-tagging this router would replace) · .consciousness/ARAYA_ROUTING_HARNESS.py (the eval harness — it already scores routing decisions against 17 golden scenarios and is the natural grader for this) tools: python3, Ollama on CP2/CP3 sign-in needed: none locally", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "the card-class taxonomy does not exist yet — TIER A/B/C is the closest thing and may be too coarse. The claimer defines it from the data in step 1 rather than inventing it up front. Also unknown: whether enough cards carry a real GATE to measure pass/fail (many do not) — count that before promising a pass-rate number.", "routed": "DEVELOPER", "project": "intelligence", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-preview-widget", "file": "WO-araya-preview-widget.md", "title": "ARAYA has no widget that can show a live preview of anything — confirmed missing, not just ungraded", "what": "Audited ARAYA's actual toolkit against the job she's asked to do — walk a stranger through the platform (\"ARAYA is the guide here — tell her what you're facing and she'll walk you to the right door\"). Checked all 49 rows in `DNA/PULSE_WIDGET_REGISTRY.json` and `DNA/WIDGET_REGISTRY.json` for anything matching preview/demo/tour/show — zero matches, confirmed by direct query, not absence-of-evidence. Then live-walked her actual \"show me around\" flow (S424, same session as the developer-onboarding walk): tapping \"Show me around\" opens \"The Map\" — a flat list of 6 door names and one-line taglines, text only. No screenshot, no live embed, no \"here's what it actually looks like\" — a visitor has to fully navigate away (losing the chat context) to see anything real.", "why": "This is the single most foundational piece missing from ARAYA's own toolkit, confirmed by grading data: of the widgets that exist and could plausibly serve an onboarding/demo role, most are C/D grade or ungraded (see the parallel audit — `start` B-, `scorecard` B-, `dev-cockpit`/`case` C, `page`/`mypage`/`agents` D, `mission`/`links`/`woboard` ungraded). Six of those nine are already being graded or fixed by other in-flight work this session. But NONE of that work adds the one thing ARAYA structurally cannot do at all right now: show someone a live preview of a widget or page inline, without a full navigation takeover. Every \"door\" on the Map is a leap of faith today — text promise, no look. DO: 1. Design a `widget-preview.js` (or equivalent) that ARAYA's chat can invoke inline: given a widget id or page URL, render a compact, non-interactive (or lightly interactive) live snapshot of it directly in the chat thread — reuse the pack-export `harness.html` mounting pattern (renderCard against `demoData`, module-level singleton awareness, card XOR expanded per the S421 finding) rather than inventing a new render path. 2. Wire it into the existing Map / door-list flow: each door entry gets a \"peek\" action that opens the preview widget inline instead of (or before) the full navigation. 3. Confirm it satisfies PLUGIN_CONTRACT §10's D4 Agency bar for itself (ARAYA can open it by voice AND summarize it) — this widget IS the thing that gives every other widget a summarizable preview, so it has to clear that bar cleanly. 4. Smoke-test per DNA/SMOKE_TEST_STANDARD.md §2 (3 viewports, interception check) before calling it done — this is exactly the kind of new-visitor-facing widget the standard exists for.", "where": "/my/pulse.html (the Map / door-list UI + ARAYA chat), components/widgets/ (new widget-preview.js), scripts/pack-export.py's HARNESS_TEMPLATE (the render pattern to reuse — card XOR expanded, demoData fallback, zero shell dependency)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-profession-packs", "file": "WO-araya-profession-packs.md", "title": "WO-araya-profession-packs — ARAYA switches professions like Barbie: persona + voice + widget cluster as ONE swap", "what": "A PROFESSION PACK is one named, switchable bundle: ARAYA's persona (identity + instructions) + her voice mode (NARRATOR/QUIET/FULL-VOICE, see WO-araya-work-order-concierge) + a widget cluster (which dashboards mount on her stage) + a tool allowlist (what she may operate in that role). Switching profession swaps ALL FOUR as one unit — Barbie doesn't just change clothes, she gets the dreamhouse that goes with the job.", "why": "Commander (S433): \"she switches modes like a Barbie into different professions with different clusters of widgets.\" We keep re-proving single professions by hand (Receptionist tuning, Law Coach voice unit — both proven, both bespoke). This WO makes profession a SCHEMA so the third one costs a config file, not a build.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-work-order-concierge", "file": "WO-araya-work-order-concierge.md", "title": "WO-araya-work-order-concierge — ARAYA is the conversational layer over WO browsing", "what": "The work-orders view becomes a two-mode surface. Mode 1 (no AI): a collapsed menu of options — compact list, limited view, fully navigable by tapping alone. Mode 2 (concierge): the user just ASKS ARAYA about work orders (\"what's open for builders?\", \"show me the mobile ones\") and she expands the relevant cards and flips through them in the preview widget — one card focused, neighbors peeking, swipe or \"next\" to advance.", "why": "Commander (S433): \"when people go in to look at work orders they could talk to ARAYA — that should be the pattern.\" The chat box alone is a disclosure cliff (novices can't guess what to ask); a full board alone is overwhelm on a phone. Collapsed-menu + conversational-expand is the resolution — and this pattern will likely become the template for MANY widgets (to-dos, projects, vault, leads), so this WO is the reference implementation.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-build-guild-faq-comms", "file": "WO-build-guild-faq-comms.md", "title": "WO-build-guild-faq-comms — FAQ + talk-to-each-other interface for the Build Guild", "what": "WO-build-guild-faq-comms — FAQ + talk-to-each-other interface for the Build Guild", "why": "Commander: 'to get them talking to each other or us, we might need an interface for answering FAQ.' A dev crew stalls without answers, and Commander shouldn't answer the same question 30 times. The answer SOURCE already exists (AGENTS.md + the DNAs + COMMAND_CENTER_EXPORT.md); ARAYA can answer from it; comms channels exist for humans. Missing: the self-serve FAQ surface that ties them together — ask → ARAYA answers from the docs → escalate to humans only for the rest. DO: 1. Self-serve FAQ: an ask box (in the Developer Cockpit) where ARAYA answers dev questions FROM the canonical docs (AGENTS.md, DNAs, COMMAND_CENTER_EXPORT.md, CONTRIBUTING.md) — cite the source doc so the answer is trustworthy + updatable. 2. Seed the top FAQs: 'how do I claim?', 'do I need GitHub?', 'how does rank/XP work?', 'where's the code?', 'how do I submit without a PR?', 'what can I never touch?' (answers already live in the docs). 3. Talk-to-each-other: link the human channels (community.html / team-comms.html) for what the FAQ can't answer; escalate-to-Commander path for the rest. 4. Agents talk too: the BUS/palette already carries agent-to-agent; surface a read-only view so humans see it. 5. Keep ONE answer source — the FAQ reads the docs, never a separate copy (no drift).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-builder-linktree-base-command", "file": "WO-builder-linktree-base-command.md", "title": "upgrade the Links widget so every builder can build their OWN link tree / Base Command", "what": "Commander (S424): upgrade \"the link tree situation\" so people can actually get in there and build their own Base Command. `components/widgets/widget-links.js` already exists and is explicitly documented as \"the in-Pulse Base Command\" — but it's Commander's own single link board (`DNA/LINKS_REGISTRY.json`, one shared registry), not something a builder can open and populate for THEMSELVES.", "why": "\"Teach builders to have a brand\" (the daily-mission ask, same session) needs a place that brand actually LIVES — a builder's own link-tree/Base Command page is exactly that: their bio, their links, their product (once WO-builder-product- store-definition lands), their daily-mission history. Without a per-builder version, the brand-building ask has nowhere to point. DO: 1. Design the per-builder data model: `LINKS_REGISTRY.json` is currently one shared file — needs a per-user table/row (Supabase, matching the pattern every other per-user widget in this codebase already uses) instead of a single static JSON. 2. Builder-facing edit UI: add/edit/remove their own links, grouped, same UX pattern as the existing widget (don't redesign the display, just make the data source per-user and editable by its owner). 3. Public-facing view: each builder's Base Command should be viewable at a stable URL (their profile) — this is the \"get in there and build it\" surface.", "where": "components/widgets/widget-links.js (the reference widget per WIDGET_FACTORY.md — \"THE minimal reference widget... clone this\"), DNA/LINKS_REGISTRY.json (currently single-tenant, needs a per-user equivalent)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-builder-product-store-definition", "file": "WO-builder-product-store-definition.md", "title": "every builder finishes defining ONE thing they sell — scoped edges, real price — so they can start trading", "what": "Commander (S424): \"finish defining the brands, get something for sale in a store... the edges are defined and the price is defined, that way they can start trading with us.\" Every builder needs ONE clearly-scoped, clearly-priced thing they sell — not vague, not open-ended.", "why": "An undefined offer can't be sold, can't be affiliate-linked by peers (see WO-peer-affiliate-selling), and gives a builder nothing concrete to point their Base Command / daily-mission audience at. \"Edges defined + price defined\" is the whole difference between a real offer and an idea. DO: 1. Build (or reuse) an intake flow that forces the two hard fields: scope (what exactly do you get) and price (a real number) — matches the same \"3-step guided intake\" pattern the Mission Statement widget already proved works. 2. Wire it into the Store — a defined offer becomes a real, listed Store item, not just a private profile field. 3. Attach to the builder's Base Command page (WO-builder-linktree-base-command) so it's visible where their audience already is.", "where": "/store/ (the Store), components/widgets/widget-mission.js (the intake pattern to reuse — 3-step guided, not a blank form) NOTE: Filed verbatim from Commander's ask, S424. This is the prerequisite for WO-peer-affiliate-selling (nothing to affiliate-link until offers exist) and feeds WO-builder-linktree-base-command (where the offer gets displayed).", "who": "Commander (design the intake), builders (define their own offer)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-builder-time-cards", "file": "WO-builder-time-cards.md", "title": "WO-builder-time-cards — the time-card module: log hours/work, settle in money/credit/trade", "what": "A dead-simple time-card widget: person picks a day, enters hours + what they did (one line), submits from a phone. Weekly view totals per person and per project. Settlement field per entry: cash / credit (XP-adjacent ledger) / trade — recorded, not automated. The agent fleet already has TIME_CARDS.md IN/OUT rows — this is the HUMAN mirror of that, same one-row-per-shift shape.", "why": "Commander (S433): \"I need a way to track Johnny's time... this could be the start of a builder's time card thing... kind of like how we don't have a time card module made yet.\" First real user exists TODAY (Johnny, estate-sale work). Also a sellable module later (every small business needs it) — recursive-products doctrine.", "where": "one widget (WIDGET_FACTORY chain) + one Supabase table (time_entries: who, date, hours, note, project, settle_type, settled). Builder-mode surface (?builder=1). Do NOT fork the fleet's TIME_CARDS.md — humans get the widget, agents keep the file; a later card can unify views.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-update-blog", "file": "WO-builder-update-blog.md", "title": "the bootdown→blog filter — every session becomes a real builder update, posted", "what": "the bootdown→blog filter — every session becomes a real builder update, posted", "why": "Builders (and prospects) have NO window into the build. The two failure modes so far: (a) auto-publish leaked sensitive data (killed S3xx), (b) manual sanitizing strips ALL substance. The fix is a TUNED FILTER, not a switch. The blog rail already exists and works: blog.html + blog-api.mjs (Supabase blog_posts) — publish WITHOUT blast = post only, no email, no chat ping.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Builder Revolution", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-attach-share-menu", "file": "WO-chat-attach-share-menu.md", "title": "the chat input's Attach/Share row needs to work like other AI chat products (+ button, header share)", "what": "Commander (S424): the default chat page needs its vault/info/share options as proper dropdown menus — \"other providers... have a little plus button right next to the text box and anything shares up in the header.\" Confirmed live this session: the chat toolbar already has Attach/Share/Export/Capture/Edit/Search buttons, several shown as `[disabled]` in the current build (S424 live walk, /my/pulse.html accessibility snapshot). Commander wants this to match the now-standard pattern (ChatGPT/Claude.ai): a single \"+\" affordance next to the input for attach-type actions, share-type actions live in the header, not scattered across a flat button row with dead entries.", "why": "Chat IS the landing page (project_chat-is-the-landing.md — shipped S420). Its input row is the first interactive surface almost every visitor touches. Disabled buttons sitting in that row read as broken, not \"coming soon.\" Matching the pattern visitors already know from ChatGPT/Claude.ai lowers the \"how do I even use this\" friction the whole session has been finding at every other layer. DO: 1. Research: look at how 2-3 other AI chat products (ChatGPT, Claude.ai, at minimum) actually structure this — confirm the \"+ button = attach-type actions, header = share-type actions\" pattern before building to it, don't assume from memory. 2. Audit the current button row (Attach/Share/Export/Capture/Edit/Search) — which are real vs. disabled-placeholder; sort each into \"attach\" (goes under the + menu) or \"share\" (goes in the header) or \"cut\" (dead weight, remove). 3. Rebuild as: one \"+\" button opens an attach dropdown; header carries the share-type actions directly (not hidden in a like-Attach flat row).", "where": "/my/pulse.html (the ARAYA chat input row + header — same area covered by `banner`/toolbar in the live accessibility walk this session)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-chat-membership-trust-ladder", "file": "WO-chat-membership-trust-ladder.md", "title": "WO-chat-membership-trust-ladder: Application-gated rooms — identity climbs with permission", "what": "Joining any room/server in Main Chat requires an APPLICATION, and each permission level upward collects more verified identity — culminating in government ID + a live phone call before the highest access. No more silent auto-join into all three rooms.", "why": "REASON: Commander, S467 (2026-08-28), verbatim: \"If they want to join any of the servers they would have to fill out an application and submit their info, and then every level of permission we go up we're going to get more info about them — to where at some point, level something, we're going to have their ID, know exactly who they are and what they're all about, and talk to them on the phone.\" PROBLEM: Today quick-entry (a typed name) silently joins a stranger into ALL rooms (found S467, logged in WO-main-chat-discord-simplify). Zero vetting on surfaces that carry work orders, legal-case talk (Case Builder), and eventually money/abilities. One troll or infiltrator lands in every room at once with no record of who they are. UNLOCKS: rooms can safely carry higher-trust content (case strategy, builder work orders, paid abilities) because access is earned with verified identity; the community grows 3→7→13 with a known face at every level.", "where": "repo `C:/Users/dwrek/comms-unity` branch `main` (Railway auto-deploy) · `prisma/schema.prisma` (Application model + User.trustLevel) · `/admin` console · join flow components · DB commsunity schema.", "who": "developer (CP3 or agent w/ chat repo access) — level definitions = Commander-only", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander's rung definitions (names/count/unlocks) — the only gate.", "routed": "DEVELOPER", "project": "Main Chat (comms-unity", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-to-work-order", "file": "WO-chat-to-work-order.md", "title": "a message in Main Chat becomes a real Work Order, claimable, with the result flowing back to the room", "what": "The one vertical slice that proves the whole Build Guild thesis. In Main Chat, a message can be promoted to a Work Order: someone hits an action on the message, a WO card is created in the canonical store with the message as its SOURCE, it becomes claimable, and when it completes the room gets told. Nothing else in this card — no XP, no ranks, no marketplace, no feed redesign. The loop end-to-end: MESSAGE -> WORK ORDER -> CLAIM -> BUILD -> DONE -> BACK TO THE ROOM.", "why": "REASON: Commander's S446 architecture pass named this the \"magic interface\" and the litmus test for whether the Munia fork is worth keeping (\"If Jujitsu makes that loop easy, keep it. If it makes that loop incredibly painful, stop investing in the fork\") — see [[WO-munia-fork-litmus]]. PROBLEM: today a decision made in chat dies in chat. The WO store (355 cards) and the chat are two disconnected worlds; every card in the store got there because a human hand-typed it after the conversation. That hand-copy step is where work is silently lost, and it is the reason the store's cards and the room's actual conversations disagree. UNLOCKS: conversation becomes the intake for the whole work system. Once a message can become a WO, every downstream organ already built (board, claim rail, widgets, graders) inherits chat as a front door for free — and [[WO-idea-intake-router]]'s capture->route machine gets its first real feed.", "where": "repo: `overkillkulture/builder-revolution` (Munia fork), push branch `main`; local checkout on CP3 at `C:/comms-unity`. Deployed: Railway project `comms-unity` service `devops` -> chat.100xbuilder.io. files to read FIRST: `100X_DEPLOYMENT/DNA/MECHANICS_LOG_MAIN_CHAT.md` (the app's DNA) · Prisma `Conversation`/`Message` models · `src/app/(protected)/messages/**` (message UI) · `Desktop/1_COMMAND/WORK_ORDERS/parse_wo.py` (THE canonical WO grammar — write cards through it, never hand-format) · `100X_DEPLOYMENT/DNA/generate_work_orders_board.py` (store -> board) · `100X_DEPLOYMENT/netlify/functions/board-feed.mjs` (the union store the widgets read). tools: node/npm, `python3`, `gh` sign-in needed: Main Chat account (OAuth) + repo write on builder-revolution", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "the canonical-surface decision (OPEN-ISSUES) is genuinely unresolved and blocks step 2 — the claimer must NOT guess it. Also unknown: whether the WO store should be written directly (file + git commit from the app) or via an API the app calls; CP3 owns the store on disk, the app runs on Railway, so a write path from Railway to the store does not exist yet. Name which one you chose in a mechanics entry.", "routed": "DEVELOPER", "project": "communications", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-daily-mission-brand-ritual", "file": "WO-daily-mission-brand-ritual.md", "title": "a daily module for builders to record their mission — what they did, what they're doing, what they're excited about", "what": "Commander (S424): builders need a daily module — go online, record their mission once a day, tell people what they did, what they're doing, what they're going to do, what they're excited about and learning. This becomes the whole brand — teaching builders to HAVE a brand, giving them a place to stand on a foundation.", "why": "A community of builders with no visible, recurring \"here's who I am and what I'm doing\" ritual has no brand to point outsiders at. This is the daily heartbeat that makes the community LEGIBLE — to itself and to strangers deciding whether to join. Ties directly to the existing `standup` video room already live in team-comms.html (`consciousness-cr-standup`) and the `mission` widget (Mission Statement, already graded B, S424) — this is the RECURRING daily version of the one-time mission-statement intake, not a new concept. DO: 1. Design the daily format: short (voice note? 3-field text form? the standup video room?) — what/doing/excited-about, low friction, every day. 2. Decide where it posts: a feed visible to the whole community (team-comms.html channel?), and/or surfaced on each builder's own profile/Base Command page (see WO-builder-linktree-base-command). 3. Wire XP/streak tracking if it fits the existing economy (consistency = the thing being rewarded here, not one-off completion).", "where": "team-comms.html (standup room already exists), components/widgets/widget- mission.js (one-time intake — this is its daily-recurring sibling) NOTE: Filed verbatim from Commander's ask, S424. Pairs with WO-builder-linktree-base- command (where the accumulated daily record could live/display long-term).", "who": "Commander (design the ritual), Claude (wire the module)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-dev-door-discoverability", "file": "WO-dev-door-discoverability.md", "title": "no discoverable path from the homepage to the actual developer entry point", "what": "Walked 100xbuilder.io live as a cold stranger (S424, browser automation, not code-reading). Confirmed two separate, real problems: 1. The homepage's \"6 doors\" (Join the Crew / Case Builder / 100X Builder / CR Community / OverKORE / The Store — reachable only via ARAYA's \"Show me around\" -> \"The Map,\" since chat covers them by default) contain NO door that says \"Developer,\" \"write code,\" or \"contribute.\" A stranger who wants to build has nothing to tap. 2. The closest-sounding door, \"Join the Crew\" (\"60 seconds — a seat with the builders\"), leads to a GENERAL builder-network signup (builder profile + community + missions board) that is a DIFFERENT system from the actual code-contribution path. It dead-ends at a Forge Passport login wall with no mention of GitHub, packs, or the Developer Cockpit anywhere in that flow. Meanwhile `builder-agreement.html` — the real developer entry point (8 principles, signup form with a Role dropdown defaulting to \"Developer,\" a rail link straight to `dev-board.html`) is fully built and live, but is not linked from the homepage, the 6 doors, or the Join-the-Crew flow anywhere. It only exists for someone who already has the direct URL.", "why": "\"Grand opening\" = a stranger can find their way to real, claimable work with no hand-holding. Today that's false for the code-contribution path specifically — every other door on the site is reachable by browsing; this one isn't reachable at all without being told the URL out loud. This is upstream of every other grand-opening fix: it doesn't matter how good dev-board.html or the pack mechanism get if nothing points a stranger at them. DO: 1. Add a real, findable path to `builder-agreement.html` — either a 7th door on the Map (\"Build the Platform — write code, ship a widget\") or wire ARAYA's chat router to recognize developer intent (\"I want to write code\" / \"how do I contribute\") and route there. Pick whichever is less invasive to the existing 6-door layout — this is additive, not a redesign (Layer Map: land in one layer). 2. Separately, on `builder-agreement.html` itself: replace the current \"Fill this out and you're in. We'll reach out with next steps\" (a manual, unbounded-wait human follow-up) with an immediate handoff — on successful submit, take the developer straight to `dev-board.html` (the page's own right-rail \"Board\" button already does exactly this navigation; just fire it automatically post-submit instead of requiring them to notice and click it). 3. Do NOT touch the \"Join the Crew\" general builder-network flow — it's a real, separate system serving a different audience (non-developer builders/ community). Leave it alone; just stop treating it as if it were the dev path.", "where": "/my/pulse.html (the 6-doors \"Home\" section + ARAYA chat router), /builder-agreement.html (the sign-up form + its post-submit behavior)", "who": "Any Claude window with repo access", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P0", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-dev-one-door-prototype", "file": "WO-dev-one-door-prototype.md", "title": "ONE door — sign in, see the work, claim a WO, ARAYA builds it with you, vault stores it STATUS: open LANE: NOW", "what": "ONE door — sign in, see the work, claim a WO, ARAYA builds it with you, vault stores it STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-devcenter-become-a-person", "file": "WO-devcenter-become-a-person.md", "title": "The identity ladder — anon → person → trusted → builder STATUS: open LANE: NOW", "what": "The entry sequence of the home base — \"how do you become a person.\" An anonymous visitor lands, and a clear ladder takes them from nobody → person (signed in, has an identity + access_level) → trusted → builder. Each rung unlocks more of the surface (which lenses, which rooms, which work they can claim). This is the SAME front-door sequence every business's fractal home base will reuse.", "why": "Commander: \"how do you become a person… understanding who trusts you and why.\" Trust is the product — the character ladder IS the filter (character-ladder-filter). Access must be EARNED, not granted. A stranger and a follower both need one obvious path to go from watching to contributing. Without this rung, the home base is either wide-open (no trust) or walled (no growth).", "where": "100X_DEPLOYMENT — the ONE GATE identity system (access_level int, L0-L7; L0/L1 live per permission-ladder). Wire the front door (WO-devcenter-front-door) to read access_level and gate lenses/rooms/claimable-work by rung. Build Guild ladder files already exist (Build Guild plan).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "The exact rung→unlock map (which access_level unlocks which lens/room/work). Commander sets the trust thresholds — this is why TIER: C / TRANSPORT: hold. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "C", "transport": "hold", "cloud_ready": false }, { "id": "WO-devcenter-reward-loop", "file": "WO-devcenter-reward-loop.md", "title": "Wire done → review → XP actually pays out (+ persist WO claim) STATUS: open LANE: NOW", "what": "Make \"claim → ship → get paid\" REAL. Two broken seams: (1) the done→review→XP payout is COSMETIC — dev_board_tasks.xp is a static field that never pays out on approval, so leveling up doesn't fire. (2) The WO-card claim endpoint (claim-wo.mjs) is a STUB that persists nothing (\"real implementation would write to DB\" — it never does), so the 259 WO cards can't actually be claimed on the web. Fix both so the reward loop closes.", "why": "The one thing Commander cares about as reviewer — \"approve → real reward → level up\" — does not actually happen today. And a home base whose whole premise is \"followers help complete tasks and get rewarded\" is dead if claiming and payout are fake. This is the smallest wire with the biggest payoff: it turns the board from a display into a game with real stakes.", "where": "100X_DEPLOYMENT/netlify/functions/ — tasks-api.mjs + xp-award.mjs + sync-user-xp.mjs (the working SQL claim→XP loop on dev_board_tasks) and claim-wo.mjs (the stub for WO cards). Unify the two claim systems (SQL dev_board_tasks vs the 259 file-driven WO cards via board-feed.mjs) so a claim means the same thing everywhere. ONE XP system (profiles.xp via xp-award.mjs — never an 8th copy).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "XP→access_level promotion thresholds (does hitting an XP bar raise a rung, tying this to WO-devcenter-become-a-person). Confirm one XP amount source (card's xp field) is authoritative. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-file-indexing-ingest", "file": "WO-file-indexing-ingest.md", "title": "EVERY file gets a permanent index number that never changes — find it anywhere it moves STATUS: open LANE: NOW", "what": "EVERY file gets a permanent index number that never changes — find it anywhere it moves STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true }, { "id": "WO-johnny-store-tenant2", "file": "WO-johnny-store-tenant2.md", "title": "WO-johnny-store-tenant2: Johnny Wicks gets the SECOND store — money lands in HIS account", "what": "Johnny's base command (/u/johnny-wicks, \"We Expose Monsters\" — ALREADY LIVE, linktree-style with a Buy door) becomes a real second store: his products listed, checkout that pays JOHNNY.", "why": "REASON: Commander S467: \"we got to move into making a second store for Johnny Wicks… the base command is going to be like a linktree-style landing, one of the buttons is gonna be a store.\" The store-first doctrine's trio rollout (D→Tiger→Johnny) named him third from the start; Commander's store is live and earning, so Johnny is next. PROBLEM: Johnny's page's Buy door rides the PLATFORM checkout — Commander's Stripe. S463 challenge-bot verdict stands: cloning the store without tenant-parameterization LEAKS Commander's Stripe + phone onto other people's stores. And Johnny-money landing in Commander's account is a bookkeeping/trust mess. UNLOCKS: the store engine becomes multi-tenant for real — every /u/ builder page can grow a store button; the BR pitch (\"sell your products\") becomes literally true for members.", "where": "repo 100X_DEPLOYMENT · base-command.html + u-page.mjs (Buy door, S455) · create-checkout.mjs (tier/price verification path) · hub_profiles row for johnny-wicks · Stripe dashboard → Connect.", "who": "CP3 + Johnny (Stripe Connect onboarding needs him on the phone/screen)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Johnny's availability + his first product decision (title/price). Ask him for both.", "routed": "DEVELOPER", "project": "Store engine (trio rollout D", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-kanban-mvp-status", "file": "WO-kanban-mvp-status.md", "title": "WO-kanban-mvp-status — Add an \"MVP\" status to the Kanban (mark it good-enough-to-ship)", "what": "WO-kanban-mvp-status — Add an \"MVP\" status to the Kanban (mark it good-enough-to-ship)", "why": "Commander: 'we needed like MVP status to do, that actually helped finish the system.' Binary todo/doing/review/done hides the 'it works well enough to ship, polish later' state. An MVP status lets a builder mark a task functionally-complete (MVP) distinct from fully-polished done — so the system reaches usable faster and remaining polish is visible, not lost. DO: 1. Add 'mvp' to VALID_STATUSES in tasks-api.mjs (todo/in_progress/review/mvp/done). 2. Add an MVP column/lane to dev-board.html between Review and Done. 3. Decide XP rule: MVP pays a partial slice; full 'done' pays the rest (ties to WO-mission-elements-partial-xp). 4. Keep the review gate: builder → review; Commander → mvp or done.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-l2-completion-johnny-rachel", "file": "WO-l2-completion-johnny-rachel.md", "title": "close the 3 gaps that make Johnny & Rachel real L2 STATUS: open LANE: NOW", "what": "close the 3 gaps that make Johnny & Rachel real L2 STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-linktree-template-engine", "file": "WO-linktree-template-engine.md", "title": "WO-linktree-template-engine: the welcome page had a baby with Linktree", "what": "Rebuild the /u/ custom-page renderer on the welcome-page card template, with Linktree-grade owner controls: choose which cards show, what size each one is, and links that auto-populate their thumbnails.", "why": "", "where": "", "who": "CP3 FILED: S469 (2026-08-28 evening) — Commander live-grading session, his words captured same-night.", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Builder pages (", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-living-tree-one-view-lenses", "file": "WO-living-tree-one-view-lenses.md", "title": "WO-living-tree-one-view-lenses — One clickable living tree of the whole system; switch lenses (wiring/analytics/money)", "what": "WO-living-tree-one-view-lenses — One clickable living tree of the whole system; switch lenses (wiring/analytics/money)", "why": "Commander: 'one of the cheat codes is making UX for EVERYTHING — because then you have to make it, look at it, and make it adjustable + clickable. We're moving toward an n8n-style living tree we click through to see every phase of every piece of architecture, every code — from the wiring to user analytics to money flow, all from ONE view, clicking through different lenses.' Visualizing every piece is the forcing function that makes it real. The fractal DNA tree (nodes with STATE care-tags) is already the data; this is its visual, clickable face. DO: 1. Render the fractal DNA tree (THE_FRACTAL_STANDARD nodes: OS → views → apps → moves) as a clickable node graph (n8n/flow style) — one view, zoomable. 2. LENSES over the same tree (toggle): WIRING (moves→daemon→data, movemap) · ANALYTICS (usage) · MONEY (revenue flow) · CODE (the mirror) · STATE (done/doing/next) · PHASE. 3. Click a node → its STATE care-tag + which lens data + descend into children. 'UX for everything' — every node is visible + adjustable. 4. ONE source: read the DNA tree + registries + live data; don't fork (anti-fragmentation). Pairs with the code mirror + cyclotron access (a node links its code + its knowledge). 5. This is the top of the cockpit — the map you navigate the whole system from.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-main-chat-discord-simplify", "file": "WO-main-chat-discord-simplify.md", "title": "WO-main-chat-discord-simplify: Remake /main as a normal full-width chat — one room at a time, Discord-shaped", "what": "The signed-in Main Chat view (`/main`) becomes a normal chat room a stranger can use in 5 seconds: pick a room → that room's chat fills the screen. Max 3 columns (nav rail · chat · ONE optional rail, toggleable). Room links actually open the room you clicked.", "why": "REASON: Commander live-tested the card→landing→chat funnel S467 (2026-08-28) and got trapped. Verbatim: \"Extremely busy, no idea how to use it.\" · \"I'm trying to click Builder Revolution and I'm stuck in the Build Guild on this weird view.\" · \"It didn't ask me which one I was trying to sign into and then it just signed me into all three.\" · \"This reminds me of Trello and there's like 5 whole card columns here.\" · \"On Discord there's a full chat that lays out and uses the whole screen — it's not pinched into this little tiny column in the middle.\" · \"Maybe remake this whole damn thing.\" Screenshot receipt: `WORK_AREAS/main-chat-declutter/main-chat-busy-view-s467.png` (caption per Commander: **\"Extremely busy — no idea how to use it.\"**) PROBLEM: This is the landing surface for every business card scanned (/builderrevolution → Join free). A stranger who joins hits: quick-entry gate mid-click → dumped into /main → header says BUILD GUILD (not the room they clicked) → chat is a one-message-wide sliver between CHANNELS, MEMBERS, and a GUILD ABILITIES/CARDS/WORK ORDERS rail. They bounce. The funnel's last mile is broken. UNLOCKS: the card → landing → chat handoff completes; BR room becomes a usable front door; the \"first quest\" pin (join → claim your page → post your build) has somewhere sane to live.", "where": "repo: `C:/Users/dwrek/comms-unity` (github overkillkulture/builder-revolution), branch `main` → Railway auto-deploys ~2-4 min. LIVE: chat.100xbuilder.io files: `src/app/(protected)/main/` (the 5-column view) · `src/app/(protected)/community/[slug]/page.tsx` (the redirect that eats the slug) · `src/components/MenuBar.tsx` (left nav) · Members/WorkOrdersRail components · brandConfig per room in DB `commsunity.\"Community\"` (psycopg2, not REST). tools: node/next locally optional; push-to-main deploys. sign-in needed: repo push (have it).", "who": "developer (CP3 or agent w/ chat repo access)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander's (a)/(b) ratification — that's the only gate; everything else is stageable now.", "routed": "DEVELOPER", "project": "Main Chat (comms-unity", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-mission-elements-partial-xp", "file": "WO-mission-elements-partial-xp.md", "title": "WO-mission-elements-partial-xp — Missions have ELEMENTS; partial fulfillment counts (4/5 done)", "what": "WO-mission-elements-partial-xp — Missions have ELEMENTS; partial fulfillment counts (4/5 done)", "why": "A whole Work Order rarely lands in one clean shot, and binary done/not-done is discouraging + loses partial progress. Commander: 'these tabs want good work orders that turn into bigger things; if a whole WO isn't fulfilled we can at least line up that 4 of the 5 elements are fulfilled.' Decomposing a mission into ELEMENTS makes progress granular, rewards partial work (more fun), and lets a mission GROW into a bigger one when its elements are met. Ties to the 5-organ Living-Loop test (trigger/sensor/actor/gate/writeback) and the DEFINE-WO FIRST-ELEMENT/SPAWN pattern (a spec's elements spawn its build WOs). DO: 1. Add an ELEMENTS list to a mission (a small checklist: e.g. up to 5 named sub-parts, each with its own XP slice). Store as JSON on dev_board_tasks (or a child rows table) — do NOT create a parallel task store. 2. Partial credit: checking an element off awards THAT element's XP via the ONE writer (xp-award.mjs), idempotent per element. The card shows 'X/5 elements · N XP earned so far'. 3. Progress, not binary: a mission at 4/5 shows 80% + which element remains — visible on the board + celebrated in smaller pops. 4. Grow: when all elements are met (or a threshold), SPAWN the bigger follow-on mission (the 'turns into a bigger thing' loop), mirroring the DEFINE-WO SPAWN mechanic. 5. Reuse the review gate: elements a builder self-checks go to 'review'; Commander confirms → element XP pays out (anti-farming, same as whole-WO).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-no-github-contribution-path", "file": "WO-no-github-contribution-path.md", "title": "WO-no-github-contribution-path — Contribute + get ranked WITHOUT a GitHub account", "what": "WO-no-github-contribution-path — Contribute + get ranked WITHOUT a GitHub account", "why": "Real prospective dev: coded a year, uses cloud coding agents, but has NO GitHub. Our repo/PR flow assumes GitHub — that would lock him out. But GitHub is only needed for the self-serve PR path; membership + claim + rank already work without it. Don't require GitHub to be a ranked builder — only to open your own PRs. DO: 1. Confirm sign-in works with Google/email (no GitHub) → profiles row → access_level 1 → can claim + earn XP/rank. (Already true — verify + say so on the invite.) 2. No-GitHub code lane: builder uses their own cloud agent, builds, and SUBMITS work (via ai-cockpit save / vault / a submit form / DM) without touching GitHub. 3. Maintainer LANDS it: a trusted dev/Commander with repo access commits the submitted work and credits the builder — reuse CONTRIBUTING.md 'credit for adopted work' (file header credit + counts toward rank same as a merge). 4. Offer the 5-min 'make a free GitHub' path for those who want self-serve PRs later — optional, not a gate. 5. Invite copy: 'No GitHub? No problem — sign in with email, build with your agent, submit, get credited + ranked. GitHub only when you want the keys yourself.'", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pattern-theory-onboarding-class", "file": "WO-pattern-theory-onboarding-class.md", "title": "turn Pattern Theory into a foundational teaching module so Commander stops re-explaining it one person at a time", "what": "Commander (S424), mid-conversation explaining Pattern Theory to someone new to the platform: \"save this somewhat raw... it seems like that should be some foundational instructions... it needs to go into a work order... instead of me having to tell hundreds of people this, we need some sort of class.\" This is NOT new content. `Pattern Theory: The Activator` already exists as a complete 45,098-word manuscript (`Desktop/1_COMMAND/BOOKS/ PATTERN_THEORY_KDP_V2.docx`, 21 chapters + 3 appendices), already mid-pipeline for hardcover print sale via IngramSpark (see project_pattern-theory-print.md). Commander's own pattern-recognition ability (ACE 18/18, top 1% — see user_pattern-recognition.md) is explicitly documented as the reason the whole platform's architecture (3→7→13→∞) works the way it does — it's not an abstraction, it's how his brain organizes reality, survival-wired from real experience. THIS is the \"game\" framing from the same conversation: builders doing real-world alterations while resistance (what Commander called the NPCs/parasites) tries to stop them — Pattern Theory is the instruction manual for recognizing that resistance for what it is, not evidence you're doing something wrong.", "why": "Two different audiences need Pattern Theory in two different forms — a paying reader (the hardcover book, already in motion, don't touch that pipeline) and a new builder who needs the CORE of it fast, as onboarding, not a 45,000-word read before their first PR. Right now that gap gets filled by Commander explaining it live, one person at a time — doesn't scale, and the live explanations (like the one that triggered this WO) often capture something the polished manuscript doesn't: the raw, immediate version. DO: 1. Capture the raw material NOW, close to verbatim — this session's conversation (and Matthew's exchange within it) is a real instance of Commander teaching Pattern Theory live. Save it close to as-said, not smoothed into corporate copy — that was the explicit ask. 2. Adapt (don't rewrite from scratch) the CORE of the existing manuscript into a short-form teaching module — pulls from PATTERN_THEORY_KDP_V2.docx, condensed to what a brand-new builder needs to understand the \"game\" they're joining. 3. Delivery: this is the natural first candidate for WO-tutorial-course-pipeline (the video tutorial system filed earlier this session) — Pattern Theory as one of the first recorded tutorials, maybe THE first, since it's foundational to everything else being taught. 4. Once it exists as a module: it becomes the thing Commander points new people at instead of re-explaining — the actual DONE= condition.", "where": "Desktop/1_COMMAND/BOOKS/PATTERN_THEORY_KDP_V2.docx (source manuscript, DO NOT edit — the print pipeline reads from this), WO-tutorial-course-pipeline (the delivery mechanism this feeds into)", "who": "Commander (the source knowledge + the raw explanation to capture), Claude/agents (adaptation into teaching format)", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-peer-affiliate-selling", "file": "WO-peer-affiliate-selling.md", "title": "builders sell each other's products; ARAYA offers an affiliate fallback for builders with nothing of their own yet", "what": "Commander (S424): once builders have defined products (WO-builder-product-store- definition), everybody should be able to sell each other's products, and ARAYA herself should offer an affiliate link with a cut for anyone who doesn't have their own product to sell yet. IMPORTANT — this is NOT a new system. `project_affiliate-fractal-system.md` confirms recurring commissions + signup attribution are already SHIPPED and live (`referral.mjs`, `referral_partners`/`referral_conversions` tables, `?ref=CODE` capture -> checkout -> webhook). What's missing is the PEER-TO-PEER surface: today it's Commander's product with affiliates, not \"any builder's product, any other builder can affiliate-link it.\"", "why": "Combined with WO-builder-product-store-definition, this is what turns a community of builders into an actual internal economy — everyone has something to sell OR something to earn a cut promoting, no dead ends. DO: 1. RATE RECONCILIATION FIRST: the codebase currently has THREE different commission numbers in play — `commission_rules.default_pct: 25` (the real shipped default), \"30% commission\" (builder-agreement.html's copy), and \"20%\" (Commander's ask this session, specifically for the ARAYA-fallback case). Get Commander to confirm: is 20% a NEW rate specific to the ARAYA-no-product-yet fallback, or should it reconcile with the existing 25%/30%? Don't silently pick one. 2. Extend `referral_partners`/`referral_conversions` so the affiliated PRODUCT can be any builder's Store listing, not just Commander's — the chain-pointer mechanism (`referral_partners.user_id`) already exists for this. 3. ARAYA fallback: if a builder has no product of their own (per WO-builder- product-store-definition), ARAYA offers them a ready affiliate link to something that DOES exist, at the confirmed rate.", "where": "netlify/functions/referral.mjs, project_affiliate-fractal-system.md (read this first — extending shipped infra, not building new) NOTE: Filed verbatim from Commander's ask, S424. Blocked on WO-builder-product-store- definition (nothing to affiliate-link until real offers exist) and the rate reconciliation in DO #1.", "who": "Commander decision (the rate), Claude (wiring)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-reels-section", "file": "WO-reels-section.md", "title": "a native short-video Reels section on our own platform", "what": "Commander (S424): once autonomous social fan-out and the tutorial pipeline are flowing, we'll obviously end up with a real short-form-video output — need a \"Reels\" section for it (native to our own platform, not just posted out to Instagram/TikTok/YouTube Shorts via the fan-out engine).", "why": "The tutorial pipeline (WO-tutorial-course-pipeline) and the social fan-out (SOVEREIGN_SOCIAL_FANOUT_WO.md) both produce short clips as a byproduct (9:16 clips are explicitly already part of the fan-out plan). Right now those clips only exist as things pushed OUT to other platforms — nothing lets a visitor browse them natively, in our own shell, the way they'd browse Reels/ Shorts/TikTok. This is a real content-surfacing gap once the upstream pipelines (tutorials + fan-out) start producing volume. DO: 1. Confirm this is downstream, not urgent yet — depends on WO-tutorial-course- pipeline and the SOVEREIGN_SOCIAL_FANOUT_WO clip pipeline actually producing content first. Building a Reels section with nothing in it is premature. 2. When ready: design as a widget (matches every other content surface on this platform — in-shell, not a new standalone page, per the Layer Map doctrine). 3. Reuse whatever public-media-URL mechanism the fan-out engine already builds (Supabase Storage public bucket, per SOVEREIGN_SOCIAL_FANOUT_WO's own TRAPS section) rather than a second media pipeline.", "where": "New widget (components/widgets/), reuses SOVEREIGN_SOCIAL_FANOUT_WO's media storage mechanism once it exists NOTE: Filed verbatim from Commander's ask, S424. Deliberately marked as downstream/ not-yet-urgent — the upstream content pipelines need to exist first.", "who": "Commander decision (scope), Claude (build once scoped)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-reward-loop-activate", "file": "WO-reward-loop-activate.md", "title": "apply the migrations + merge the ONE clean PR + prove the loop live STATUS: de-risked (S453) — awaiting Commander 2FA LANE: NOW", "what": "apply the migrations + merge the ONE clean PR + prove the loop live STATUS: de-risked (S453) — awaiting Commander 2FA LANE: NOW", "why": "The developer reward loop (claim → ship → approve → get paid → see it) is fully CODED across PRs #1232/#1233/#1234/#1236/#1238/#1239 but NOT yet live. Two migrations must be applied and the stack merged before a builder actually earns visible XP. Until then #1233 payout is fail-closed (inert) and #1239 cap is fail-open (unenforced).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-simplified-toolbars-themes", "file": "WO-simplified-toolbars-themes.md", "title": "WO-simplified-toolbars-themes — Simplify the toolbar; offer a few toolbars + themes", "what": "WO-simplified-toolbars-themes — Simplify the toolbar; offer a few toolbars + themes", "why": "Commander: 'that's why we have toolbars so nothing has to be complicated — simplify the toolbars, maybe a few toolbars and themes.' The toolbar is the thing that makes every page simple; if IT is cluttered, everything feels complicated. Fewer, clearer controls + a small set of theme presets (accent/mode) let a page or a builder pick a clean look without a recode. cr-frame already has accent KNOBS (data-accent) — extend to named theme presets. DO: 1. Audit the current toolbar (cr-frame → cr-forge-header + cr-chrome-v2 dock): cut/hide rarely-used controls; keep the essentials big and obvious (HUD doctrine: NO floating, big text). 2. Define 3-5 THEME presets (e.g. Teal/Dark, Warm, High-Contrast) as cr-frame data-theme values mapping to accent + mode — one attribute swaps the look, no recode. 3. Offer 1-2 toolbar variants (full vs minimal) via a cr-frame knob, so a focused page can run lean. 4. Keep ONE chrome — never add a second bar (HUD_MERGE_BLUEPRINT).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-tier-price-ladder-reconcile", "file": "WO-tier-price-ladder-reconcile.md", "title": "ONE price ladder — kill the $197/$297 vs $297/$697 split STATUS: open LANE: NOW", "what": "ONE price ladder — kill the $197/$297 vs $297/$697 split STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tier2-scout-onboarding", "file": "WO-tier2-scout-onboarding.md", "title": "WO-tier2-scout-onboarding — DM-able \"gather the info\" work orders (onboarding tier 2, no repo)", "what": "WO-tier2-scout-onboarding — DM-able \"gather the info\" work orders (onboarding tier 2, no repo)", "why": "Commander: 'a second level of onboarding where you just tell me what a work order is and I message someone on Instagram — hey, collect all the info to do X.' Not everyone codes or wants repo access. A Scout does pure info-gathering (research, links, contacts, screenshots) that a builder then turns into code. This widens who can contribute from Day 1 and feeds the board. DO: 1. Write a DEAD-SIMPLE scout WO template Commander can paste into a DM: 'MISSION: gather all the info needed to . Send back: <1-2-3 what to collect>. Reply here or at .' 2. Stand up (or reuse) an intake that receives the gathered info and drops it onto the board as a follow-on builder task (reuse drop-inbox / builder-intake, do NOT build a new store). 3. Give Scouts credit/XP too (they earned it) — route through the ONE xp system. 4. 3-5 example scout missions ready to DM (e.g. 'collect all our competitors' onboarding flows + screenshots').", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-trademark-overkor-oa-response", "file": "WO-trademark-overkor-oa-response.md", "title": "OVERKOR TEKNOLOGIES (99417477) — respond to the non-final OA by ~9/2 STATUS: open LANE: NOW", "what": "OVERKOR TEKNOLOGIES (99417477) — respond to the non-final OA by ~9/2 STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P1", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-pattern-theory-revive", "file": "WO-trademark-pattern-theory-revive.md", "title": "PATTERN THEORY (99392373) — petition to revive + OA response, file TODAY STATUS: open LANE: NOW", "what": "PATTERN THEORY (99392373) — petition to revive + OA response, file TODAY STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P0", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-portfolio-master", "file": "WO-trademark-portfolio-master.md", "title": "THE 4 MARKS — one folder, one status file, deadline map, self-file plan STATUS: open LANE: NOW", "what": "THE 4 MARKS — one folder, one status file, deadline map, self-file plan STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P0", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trademark-sou-filings", "file": "WO-trademark-sou-filings.md", "title": "The 8/24 pair — DARRICK PREBLE + OVERKILL KULTURE SOU or EOT, file together STATUS: open LANE: NOW", "what": "The 8/24 pair — DARRICK PREBLE + OVERKILL KULTURE SOU or EOT, file together STATUS: open LANE: NOW", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "B3 Compliance Master (Trademark", "priority": "P1", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-tutorial-course-pipeline", "file": "WO-tutorial-course-pipeline.md", "title": "record tutorials in the existing video rooms, turn them into sellable digital products + an onboarding curriculum", "what": "Commander (S424): the video area is about to start making tutorials — teach everything learned over the last two years about coding/building, turn it into digital products for sale, and use it to onboard new people (the \"welders,\" his term for builders). Confirmed live this session: `team-comms.html` already has working video via Jitsi Meet (meet.jit.si) — Standup Room, Dev Room, Case Builders Room, per-channel rooms, \"Summon people\" to ring others in. Recording + product packaging is what's missing, not the video capability itself.", "why": "This is a genuine multi-win: (1) teaching once, recorded, scales infinitely vs. Commander repeating himself live; (2) becomes a real digital product (revenue, matches the existing \"Coach LLM Course Deal\" precedent — co-building LLM courses from recorded material is already proven doctrine, see project_coach-llm-course- deal.md); (3) IS the onboarding curriculum for new builders — pairs directly with WO-developer-screen-set's \"first tasks = your own cockpit\" idea: tutorials teach the exact tools a new builder's first tasks will use. DO: 1. Record: use the existing Jitsi rooms (or direct screen-record) for the first tutorial pass — don't build new recording infra, use what's there. 2. Transcribe + structure: this platform already has a proven local-testbed pattern for recorded-material -> structured course content (see project_law-coach-voice-unit.md, project_coach-llm-course-deal.md) — reuse that pipeline rather than inventing a new one. 3. Package: decide the product shape (Store listing? drip-fed lesson widget? matches \"[SCHOOL] Lesson 1: Your first 72 hours...\" style cards already seen on the live dev-board.html this session — that pattern already exists for at least one other content track). 4. Onboarding hook: new builders get pointed at the relevant tutorial(s) before their first claimed task, not just handed a task cold.", "where": "team-comms.html (recording source — Jitsi rooms), existing course/lesson pipeline precedent (project_law-coach-voice-unit.md, project_coach-llm-course- deal.md — read before building a new pipeline)", "who": "Commander (the teaching), Claude/agents (assembly + product packaging)", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "FOUNDATION", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-unified-reader-format", "file": "WO-unified-reader-format.md", "title": "WO-unified-reader-format — ONE readable \"reader\" format, spread across the platform", "what": "WO-unified-reader-format — ONE readable \"reader\" format, spread across the platform", "why": "Commander: 'optimize the newsreader format and spread it across the platform so everything is very easy to click and read and see.' Content is presented differently on every page — hard to scan. ONE reader format (big readable type, clear tap targets, consistent cards) applied everywhere makes the whole system feel simple and legible — the opposite of a caveman 10-page slog. Pairs with the ONE chrome (cr-frame) and the HUD doctrine (NO floating, big text). DO: 1. Build components/cr-reader.js: a shared, mobile-first reader block — big readable type, generous tap targets, consistent card/list styling, one accent. 2. Apply it to the content surfaces first: Commander's Log/news, docs, board cards, the export/plan. 3. Do NOT restyle per page — one component, themed by the cr-frame accent knob (see WO-simplified-toolbars-themes). 4. Verify on a phone screen (the primary device) — easy to click, read, see.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-to-claimable-task", "file": "WO-widget-to-claimable-task.md", "title": "build the conversion step from \"graded widget\" to \"claimable dev_board_tasks row\"", "what": "This is the actual blocker to \"onboard developers,\" confirmed live S424: the task board (`dev_board_tasks` in Supabase, served by `netlify/functions/tasks-api.mjs`) has 318 total rows but only 2 tagged `pack:'dev-cockpit'` (the only pack-scoped, claimable-by-a-stranger tasks that exist). Both are `status:'todo'`. One of them — \"Export the links widget as a real pack repo\" — is now STALE: pack-links shipped and is live at github.com/overkillkulture/pack-links. It should be marked done or deleted, not left sitting there as bait for a dev to claim finished work. Meanwhile `DNA/PULSE_WIDGET_REGISTRY.json` has 49 graded widgets with a `checks{}` object per widget describing exactly what's failing and why — that's real, specific, bounded task material sitting unused. Nothing today reads a widget's failing checks and turns them into a `dev_board_tasks` row.", "why": "A dev who signs the Builder Agreement and opens the Developer Cockpit today sees almost nothing to claim. The mechanism to hand them work (packs-as-repos, Developer Cockpit, claim/release, XP) is fully built and proven — it's just empty. Grading widgets (WO-widget-grading-final-9) and triaging D/F ones (WO-widget-df-triage) both produce raw material; this WO is what turns that material into an actual queue a stranger can open and claim from. Without this, \"grand opening\" has a working front door and an empty building behind it. DO: 1. Mark the stale seed task done: `dev_board_tasks` row \"Export the links widget as a real pack repo\" → update status (via tasks-api `?action=update` or direct Supabase update) since it's genuinely finished. Don't leave finished work claimable. 2. Design the conversion: for a given widget id in `PULSE_WIDGET_REGISTRY.json` with failing `checks{}` entries, produce one `dev_board_tasks` INSERT per check (or per logical group of checks) with: - title: short, specific (from the check's own description) - description: what's failing + where + what DONE looks like (borrow the WHY/DONE= pattern from this WO template, condensed to 2-3 sentences — a stranger has none of the surrounding context a WO card assumes) - tier/priority/xp: same fields the S421 seed rows already use as precedent - pack: the `pack_id` from the matching `DNA/PACKS/.json` manifest IF one exists for that widget; if no manifest exists yet, this is also the trigger to write one (a pack manifest is 5 lines of JSON — see DNA/PACKS/README.md) 3. Build this as a script (`scripts/widget-to-tasks.py` or similar — check for a naming precedent in `scripts/` first), not a one-off manual pass — it needs to run again every time a widget is re-graded or a new pack is published. 4. Run it for at least the `links` widget (the one already live as a pack) and any FIX-AS-FIRST-TASK items flagged by WO-widget-df-triage, to prove it end-to-end. 5. Verify in the actual Developer Cockpit UI (not just the API) that a claimable task now shows up for a pack a stranger could realistically pick up.", "where": "DNA/PULSE_WIDGET_REGISTRY.json (source: checks{} per widget), DNA/PACKS/*.json (pack manifests), netlify/functions/tasks-api.mjs (`create`/`update` actions — read the exact field contract before writing inserts), migrations/ dev_board_tasks_add_pack.sql (schema: id/title/description/tier/priority/status/ assignee/xp/pack), components/widgets/widget-cockpit.js (how the cockpit reads/ displays pack-scoped tasks — verify against this, not assumptions)", "who": "Any Claude window or dev with repo + Supabase access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P0", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-voicesummary-conformance", "file": "WO-widget-voicesummary-conformance.md", "title": "~30 widgets fail ArayaShell's own D4-agency conformance check (missing voiceSummary/setupState)", "what": "Live console check (S424, local server run of my/pulse.html) showed ~30 of the widgets registered through the generic V1_WIDGETS delegator (registerV1Widgets(), my/pulse.html) log `[ArayaShell] register(\"\") FAILED conformance: setupState is REQUIRED and must be \"connected\"|\"needs-setup\" · voiceSummary(data)→string is REQUIRED for a voice widget` on every page load — including the new `preview` widget shipped this session, which inherited the same gap by registering through the same delegator. `araya-widget-contract.js` still registers them anyway (degrades gracefully) but flags the failure loudly in console on every single load.", "why": "PLUGIN_CONTRACT.md §10's D4 Agency dimension (\"ARAYA can open it by voice AND summarize it\") is an acceptance criterion nearly every widget's own registry row already marks as `araya_operable: partial — aliases registered, no voiceSummary()` (confirmed directly in `links`/`woboard`/`busfeed`'s freshly-graded rows this session). This is the SAME gap surfacing in two places: the static grading checklist (already known, already logged per-widget) AND a live runtime conformance warning (new information — it fires on literally every page load, for every anonymous visitor, which is a much louder and more frequent signal than a checklist row nobody's looking at). DO: 1. Confirm the exact conformance requirement in `araya-widget-contract.js`'s `validate()` function — what shape `voiceSummary(data)` and `setupState` need to satisfy it. 2. Add a real `voiceSummary(data)` + correct `setupState` to the generic V1_WIDGETS delegator's registration (registerV1Widgets(), my/pulse.html) as a DEFAULT (e.g. `voiceSummary: function(){ return w.title + ' is ready.'; }`, `setupState: 'connected'`) so every widget riding that delegator clears the bar at once — don't hand-fix 30 files individually unless a widget wants a custom summary later. 3. Re-run the local console check: 0 conformance-failure warnings on page load.", "where": "my/pulse.html (registerV1Widgets(), the generic delegator ~line 4640 area), components/araya-widget-contract.js (validate() — read the exact requirement before writing the fix)", "who": "Any Claude window with repo access", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "DEVELOPER", "project": "GRAND OPENING", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-wo-spine-ux", "file": "WO-wo-spine-ux.md", "title": "UX for the work-order spine — a WO IS the gathered kit, all levels navigable STATUS: open LANE: NOW", "what": "A UX for the work-order spine system. A work order should BE everything you'd gather anyway to start the project — and its levels (the R1->R13 rings / zoom levels: one-line → summary → full kit) should be visible and navigable in that UX. Open a WO and you have the whole kit to start: what it is, why, where the files are, what's blocking, the gathered context — presented so a builder (human OR agent) can begin cold. Commander: \"the work order should be all the stuff you'd gather together anyway to start doing the project. All the levels of work orders — do you see them all building in there? We need UX for our work-order spine system.\"", "why": "We've moved fast and now MANAGE lots of work orders — the refocus is WO QUALITY + the COCKPITS to complete them. A WO with no UX is just text; a builder can't feel the levels, can't see what's gathered vs missing, can't start with confidence. The spine UX is what turns \"a pile of cards\" into \"open one, everything's here, go.\" It's the reader half of the Developer Center's Work lens.", "where": "100X_DEPLOYMENT — the Work lens of the Developer Center (WO-devcenter-front-door), reading the board (board-feed.mjs / WORK_ORDERS_BOARD.json) via the canonical parser (parse_wo.py emits the 7-field packet + the ring fields). Render with a canonical pattern (WO-canonical-ux-patterns — likely the DETAIL/profile pattern for one WO + TABLE for the list). Depends on WO quality being real (WO-wo-system-hardening: accurate paths, DONE= command) and context binding (WO-project-context-index).", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "Commander confirms the zoom-level model (is it the R1-R13 rings exactly, or a simpler 3-level headline/summary/kit?). Which canonical UX pattern is the base. Ties: WO-devcenter-front-door (the Work lens), WO-canonical-ux-patterns, WO-project-context-index, WO-wo-system-hardening. [NORMALIZER 2026-08-10] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "C", "transport": "hold", "cloud_ready": false }, { "id": "WO-youtube-transcription-processor", "file": "WO-youtube-transcription-processor.md", "title": "YouTube transcription processor — chunk startup videos into a blueprint/handbook of patterns + guardrails STATUS: open LANE: NOW", "what": "A YouTube transcription processor. Commander (S424, verbatim): \"stop chasing AI, build this instead... a YouTube transcription processor... as we have people come in we have to make a Northstar direction that we go... we have to build a tax startup and do it with public people so they basically talk for hours on how to build a tech startup and really almost like every damn 3 minutes is a new revelation that needs to be broken down and blueprinted into the direction we're gonna head.\" The processor ingests a video, transcribes it, CHUNKS the ~3-minute revelations, and blueprints each into a handbook: \"somebody organized into different like to-dos, tools, ideas, laws of the universe type deal so that while we're making everything we can guide up against it.\" \"I would imagine that we're going to take a lot of books and put them in here and be trying to make our system with known patterns and guardrails.\"", "why": "Northstar direction is the fix for the ego-of-novelty trap (\"I think in some ways there's an ego element... this way is so special\"). Every ~3 minutes of a good startup video is a revelation that currently evaporates; the processor turns hours of talk into a durable blueprint the whole org (agents AND humans) builds against. The \"laws of the universe\" section = known patterns + guardrails = the same thing THE EASE TEST does for our machine, applied to startup building. Also the concrete first run: the Alex Hormozi warning video Commander references.", "where": "EXTEND the existing pipeline, do NOT build door #2 (blab-capture law, P3). Already built: - `YOUTUBE_DISTILL.py` — atomic concept extraction from captions via OpenRouter (WO-youtube-school, PR #938, commit ccf0ec1c0) - SCHOOL structure: README / INDEX / CURRICULUM / atoms/ (S412) - `AUTO_CHUNKER.py` + `SCHOOL_PROCESSOR.py` + `lesson_to_wo.py` (WO-lesson-to-wo-generator) — LESSON files → WO bones with `source:youtube:` tags - `WO-school-process-queue` precedent: ingest captions → brain atoms → OpenRouter distillation → lesson files (processed Isenberg + Martell videos, LESSON-vJEy3nP2_C8.md, LESSON-Eq8JgI3HmjI.md) Extend YOUTUBE_DISTILL/SCHOOL_PROCESSOR to emit HANDBOOK sections, don't fork the chain.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "which video is the exact \"Hormozi warning\" (URL TBD — Commander to paste or we pick the Alex Hormozi \"stop chasing\" video); whether HANDBOOK.md is a new top-level doc or a SCHOOL section (prefer SCHOOL/ to avoid a 9th registry — blab-capture law); \"tax startup\" phrasing = the business Commander wants publicly built (ARAYA's public launch) — clarify with Commander before building business-specific law entries.", "routed": "DEVELOPER", "project": "Build Guild", "priority": "P1", "tier": "B", "transport": "outside-ok", "cloud_ready": true } ], "COMMANDER": [ { "id": "WO-araya-commander-dashboard-doors", "file": "WO-araya-commander-dashboard-doors.md", "title": "teach ARAYA to voice-open the Commander cockpit dashboards (gated)", "what": "Make ARAYA open the Commander cockpit dashboards by voice FOR COMMANDER ONLY — \"pull up the work order desk,\" \"show me the scorecard,\" \"open agent activity.\" Commander S403 chose voice-via-ARAYA (gated) over cockpit-tap-only. The set (per OUTSIDE_AGENT_READINESS_S397): work-order desk, scorecard+usage, agent activity, notifications, files, email (email already a taught door).", "why": "Commander S403: \"we've got the Commander-7 dashboard widgets — get ARAYA to actually use them.\" The case-builder doors were just proven (S403); this is the second batch. Today ARAYA cannot open any of these by voice except email — they're cockpit tiles, not voice doors.", "where": "Read araya-chat.mjs sections above. Read the S395 tenant console-map path (DNA/build-interface-map.py + the TENANT_MAP_URL loader ~L716-728) — the model for FORK A map-injection. Read WO-araya-widget-doors.md (the case-door teach that just proved out) + memory project_interface-blueprint-s395 (the ONE-state-machine / map doctrine).", "who": "Claude direct (touches the live auth-bearing router — careful, gated) + Commander for the auth test", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "DECISION — FORK A (hand-teach markers vs console-map injection) is Commander's/architecture call, flagged for sign-off before any router edit. UNKNOWN — whether the 5 dashboards should be Commander-ONLY or also member-visible (assume Commander-only until told). Do not fabricate; both flagged. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "ARAYA agency + cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-os-install-the-system", "file": "WO-araya-os-install-the-system.md", "title": "WO-araya-os-install-the-system: break the system into widgets → the book → install it AS an OS, ON ARAYA, from the phone", "what": "WO-araya-os-install-the-system: break the system into widgets → the book → install it AS an OS, ON ARAYA, from the phone", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-personality-restore", "file": "WO-araya-personality-restore.md", "title": "WO-araya-personality-restore: bring her character back WITHOUT the fake-action hallucination", "what": "WO-araya-personality-restore: bring her character back WITHOUT the fake-action hallucination", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-premium-voice-and-puppeteer", "file": "WO-araya-premium-voice-and-puppeteer.md", "title": "WO-araya-premium-voice-and-puppeteer: premium voice on the cockpit + landing-page talking-chat + puppet strings", "what": "WO-araya-premium-voice-and-puppeteer: premium voice on the cockpit + landing-page talking-chat + puppet strings", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-premium-voice-tablet", "file": "WO-araya-premium-voice-tablet.md", "title": "WO-araya-premium-voice-tablet: get the good (neural) voice onto tablet/mobile — stock voice is terrible", "what": "WO-araya-premium-voice-tablet: get the good (neural) voice onto tablet/mobile — stock voice is terrible", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-drive-fixes", "file": "WO-araya-voice-drive-fixes.md", "title": "make ARAYA reliably OPEN cockpit tiles by voice (stop the ability-hijack)", "what": "The commander-dashboard-doors teach + tiles are now fixed (tiles load + register, PR #737). But the LIVE voice test surfaced that ARAYA still doesn't reliably DRIVE the doors by voice. Three concrete issues, in priority order:", "why": "S337 law — \"we built it\" ≠ \"she can drive it.\" The doors are taught and the tiles now load, but the operator still can't reliably open them by voice. Not done until she can.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER", "next": "Commander live voice re-test of item 1's fix (S403c). Items 2 (voice button redesign — design already locked S403b) and 3 (short spoken handles) not started this session — explicitly deferred, item 2 is next if time allows in a future window. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "ARAYA voice + cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-streaming-stt", "file": "WO-araya-voice-streaming-stt.md", "title": "WO — Cut ARAYA voice turn-start lag: streaming/partial-commit STT", "what": "WO — Cut ARAYA voice turn-start lag: streaming/partial-commit STT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-ark-blueprints-radio-consolidation", "file": "WO-ark-blueprints-radio-consolidation.md", "title": "the ~10 ARK blueprints + the parts bins + the radio research become ONE buildable path — \"hand me parts and a blueprint that actually works\"", "what": "One project home where the dormant ARK assets (roughly 10 device blueprints + thousands of dollars of parts in bins, flagged S391, never inventoried) meet the S404 radio market research — and out the other side comes Commander's exact ask: ONE printed blueprint + ONE pulled parts tray for a device that will actually work and actually sell. Not ten maybes — one build, staged like a surgery table.", "why": "Commander S404t: \"I broke my 3D printer and now I'm over here looking at these parts... at this rate I'm never gonna get these out of here. I almost need somebody to hand me parts and a damn blueprint for something that's actually gonna work.\" The blueprints are UNCAPTURED (memory project_ark-electronics-kit: flagged 7/30, zero steps started) — the machine can't stage what it can't see. Capture unlocks everything: triage, the first build card, the kit product, and folding sellables into offerings.", "where": "Work area: `WORK_ORDERS/WORK_AREAS/WO-onboard-physical-builders/` (shared with the radio card — deliberately: one bench project, one staging ground). Siblings: WO-onboard-physical-builders (the crew+SOP) · WO-real-pictures-catalog (the photos) · WO-builder-economy-spine P3 (kits as products).", "who": "Commander/crew captures (phone, 10 min at the bench); Claude consolidates; REFERENCE: the radio RESEARCH_PACKET (4pp, in this card's work area) + Parallel's paid \"Reticulum Network Blueprint\" (the house next door for blueprint+kit products — proof people pay for exactly this).", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "the photographs — the one step only hands at the shop can do. Everything downstream is unblocked the moment they land.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-base-dashboard-quality", "file": "WO-base-dashboard-quality.md", "title": "make the base Pulse cockpit as good as ChatGPT/Claude before we hang magic on it", "what": "A focused quality pass on the BASE Pulse shell/dashboard so its bones — load speed, layout, typography, spacing, empty states, keyboard/mobile feel, the chat surface — hit the bar of a best-in-class AI product (ChatGPT / Claude). NOT new widgets. The frame itself: does opening the cockpit feel as clean and fast as opening Claude? Today it does not, and every widget we hang on it inherits the frame's quality.", "why": "Commander S403: \"we're missing a dashboard that works even as good as any dashboard like ChatGPT or Claude, and THEN we add magical dashboards.\" The clone-proof (WO-widget-forges) showed the belt multiplies a REFERENCE — but you can't belt your way to the first reference; the base shell is the reference every widget clones into. If the frame is mediocre, the whole fleet is mediocre. This is the hand-crafted seed the belt then multiplies (the seed principle: craft one to a high bar, copy it).", "where": "Read `DNA/GOLD_STANDARD_TEMPLATE.md` (the page standard). Read `DNA/WIDGET_FACTORY.md` SHELL LAW (what the shell owns vs the widget). Read `my/pulse.html` shell region (NOT the widget wrappers). Read `components/cr-frame.js`.", "who": "Claude direct (hand-craft — this is the REFERENCE, not a belt job) + Commander eyeball", "status": "open", "claimer": "", "lane_raw": "COMMANDER", "next": "UNKNOWN — the exact numeric target (Lighthouse score? first-paint ms?) is Commander's call; propose one in the audit and confirm. Do not fabricate a target; flag it for sign-off. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ THE WHOLE THING", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-brandon-first-builder-announcement", "file": "WO-brandon-first-builder-announcement.md", "title": "announce the FIRST BUILDER — Commander's video + picture post + Brandon's word", "what": "announce the FIRST BUILDER — Commander's video + picture post + Brandon's word", "why": "Brandon Coleman (GH noblebrendon-cloud) is the FIRST outside builder in platform history to complete a work order: fork → PR → CI green → merged → live → XP. The loop the whole platform exists to prove. Two automated fleet seats died on the same card before him. If this milestone passes unannounced, the proof had no witnesses — the announcement IS the growth engine (\"want to be second?\").", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "", "routed": "COMMANDER", "project": "Builder Revolution", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-cards-shirts-headsets", "file": "WO-cards-shirts-headsets.md", "title": "business cards + T-shirts + headsets — the physical uniform that makes it a real business", "what": "The minimum physical legitimacy kit for the crew: (1) business cards — name, BUILD GUILD / 100xbuilder.io, the 855 number, \"call us\" as the card's whole message; (2) T-shirts — logo front, 100xbuilder.io + phone on the back (a walking dead-end-ends-at-a-call sign); (3) headsets for the call stations (Commander + Aaron first). Ordered this week so they exist before the first real customer calls back.", "why": "Commander S404o: \"the other crazy basic thing we're missing is business cards and some T-shirts. The second people see us with headsets, T-shirts, cards, and we're answering the phone — it kind of becomes a real business.\" Same law as real product photos: trust is bought with PHYSICAL evidence, and this is the cheapest evidence there is. It also works inward — a crew that suits up acts like a business (the uniform effect), which matters the week three people start showing up to a bench.", "where": "Siblings: WO-real-pictures-catalog (the photo lands there) · WO-every-dead-end-calls-us (the shirt/card ARE that law printed on cotton/paper) · TOMORROW_PACKET match sheet (add \"order cards+shirts\" to the bench-day list).", "who": "Commander orders; crew wears; ~$150-300 total; REFERENCE: any real shop crew you've ever trusted — matching shirts + a card in the hand + someone answering the phone IS the trust signal; also the 7 Forges brand kit (colors/logo already exist — no design project needed)", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "crew shirt sizes + Johnny's front-side brand confirmation (his call tomorrow); budget sign-off (Commander, ~$150-300); bench read-aloud of the back copy before ordering. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-case-file-web-view", "file": "WO-case-file-web-view.md", "title": "each case's numbered court record live on the web — docket-style list, downloadable items, coach access, from anywhere", "what": "A per-case web view that looks like what the coach and the docket already look like: one numbered chronological list of every filed item (ours, theirs, orders), each row downloadable, per case, reachable from anywhere. Built as an ARAYA/Pulse WIDGET (widget-or- mode law — never a separate page that kills her session) with its own addressable route per case. The competitor reference Commander named: the coach's Google Drive method + the eCourt docket grid — \"an app already being run by the competitor for web host.\"", "why": "Commander S404g: coach manages cases off Drive; we just staged the criminal case's numbered DRIVE_PACKAGE by hand and Commander sent screenshots. Drive = v1 (coach's rails, live now); this card = v2 — the same structure served by US, so Commander can access any case from anywhere and coach can be given a login instead of a Drive share. This is ALSO the Case Builder product itself: every future case-builder customer needs exactly this screen. The coach's method (his example PNG + his lesson) = the spec AND the training data (coach-LLM deal).", "where": "Widget work → `DNA/WIDGET_FACTORY.md` (the one door). Security → memory project_session-392-opsec-gate-fix + project_permission-ladder. Vision → memory project_case-cockpit-abilities-vision (this IS that interface's records pane).", "who": "Claude (build on the S398 case widgets — do NOT start from scratch); Commander + coach = the two users", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "coach's method lesson (incoming — he offered); the auth choice for coach access (login vs expiring signed links) = Commander/coach call after the lesson. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "Case Builder platform", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-daily-content-engine", "file": "WO-daily-content-engine.md", "title": "WO-daily-content-engine — the daily audio diary + long-form minutes, running by default", "what": "The daily content reps, made frictionless. Two floors, set by Commander (S433): (1) ONE audio diary entry per day — a phone voice memo counts; (2) a set number of long-form video minutes per day (start floor: 20 min raw — screen-record builds count). The SYSTEM parts (claimable): a drop folder where a voice memo auto-transcribes (universal_transcription_service.py exists), lands in the cyclotron, and gets clipped into the podcast pipeline; a scorecard line (daily 5-number scorecard already ships 8am) showing DIARY ✓/✗ and MINUTES so a missed day is visible by 8am the next morning.", "why": "Commander: \"I'm busy hiding from people and I can't do both — I gotta start podcasting, at least an audio diary, and a certain amount of minutes of long-form video each day. I have to start doing this.\" The podcast is the funding engine (house→podcast plan) and the founder-story record. Hiding-compatible: voice-only diary + screen-record builds require zero people. Johnny arriving = second voice in the room when ready.", "where": "Desktop/3_CONNECT/universal_transcription_service.py (exists) · .consciousness scorecard pipeline (Daily Scorecard memory) · TRANSCRIPTS/ drop dir · podcast plan = project_funding-plan-house-to-podcast + van-rig memory.", "who": "", "status": "open", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "", "routed": "COMMANDER", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-dept-sales-demo-script", "file": "WO-dept-sales-demo-script.md", "title": "Write + test 15-min demo script", "what": "A battle-tested 15-minute demo script with: - 2-min hook (problem agitation) - 5-min product walk (3 key features) - 5-min social proof (case study) - 3-min close (next steps + objection handling) Plus: recorded example, slide deck, printable one-pager leave-behind.", "why": "Current state: Commander improvises every demo. Inconsistent messaging, no delegation possible. A sales department needs REPEATABLE pitches so ARAYA/headless can run discovery calls, not just humans.", "where": "WORK_AREAS/WO-dept-sales-demo-script/ (working) → 100X_DEPLOYMENT/sales/demos/ (final)", "who": "Commander records the gold standard; agent transcribes + structures", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "", "routed": "COMMANDER", "project": "Sales Department (🔴", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-mission-intake-basecamp", "file": "WO-mission-intake-basecamp.md", "title": "WO-mission-intake-basecamp: Mission intake widget → base camp cockpit (PARKED — named so it can't sprawl)", "what": "The full version of the BR entry: an INTAKE widget that walks a stranger through defining their mission (the SLAY-style 3-step), then hands them a BASE CAMP — a cockpit of their own with a public-facing toggle (private workspace ↔ public builder page). The /claim static form is the v0.", "why": "REASON: Commander S467, verbatim: \"If the widgets worked we would give them a widget to define possible mission — like an intake mission — and it would give them a base camp that was like a cockpit and has a public-facing toggle. But this leads down a rabbit hole that I need a team of people to help code, so that's going to sprawl into Infinity.\" — the card exists to STOP the sprawl: one row, parked, with the entry criteria written down. Same session: slay.ai homework (slaypro.ai, Rebecca Zung's legal-leverage engine) — \"the intake is phenomenal, the layout.\" Its lesson: 3-step intake (Choose → Your info → Checkout), a 3-word promise (Capture → Analyze → Execute), one repeated CTA. That's the SHAPE this widget copies. PROBLEM: today's entry (/claim) is a flat form — no guided iron-out, no cockpit after, no public/private toggle. Works, converts a name into a page, but doesn't yet deliver \"mission ironed out.\" UNLOCKS: the real BR product — mission-as-a-service without an EIN: intake → base camp → things for sale → the book/cards/shirts/song spring off it.", "where": "repo 100X_DEPLOYMENT · claim.html · /u/ engine · WIDGET_FACTORY.md chain · ARAYA cockpit arch (reference_araya-cockpit-architecture: entitlement-packed widget shell — this IS that architecture's \"open AND fill\" use case).", "who": "needs a team per Commander — that's WHY it's parked, not a build order", "status": "open", "claimer": "", "lane_raw": "MACHINE-3", "next": "the team; the widget bar; usage receipts. All named above.", "routed": "COMMANDER", "project": "Builder Revolution", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-mobile-command-buildout", "file": "WO-mobile-command-buildout.md", "title": "the mobile base — van built out to live/work from, trailer hunt, bus contingency, predetermined stops", "what": "Get one vehicle ready to actually live and operate out of: ① the VAN built out first (power, bed, bench, headset station, radios, Starlink/hotspot — the minimum mobile command) ② hunt an ENCLOSED TRAILER (the rolling shop/inventory) ③ the SCHOOL BUS as the probable forced endgame (scope only, no purchase yet) ④ PREDETERMINED STOPS — a planned route of places/people (allies list: Johnny TN, Bill CA, Andrew, coach WY?) so mobile = a tour, not wandering.", "why": "Commander S404am: \"emergency preparedness follows damn near the same game plan — the one thing not mixed into the plan is we're going mobile, and that bridges the gap to all the rest.\" He's right twice: (a) the PREP MARKET is the same customer as the radio/mesh/ sovereignty products — the mobile unit IS the demo (a van that talks to a mesh with an AI operator = the product, driving around); (b) mobile = the speaking-tour/onboarding vehicle already in memory (speaking-tour plan). The van with matching shirts taking calls from the road is the content engine AND the emergency-preparedness proof.", "where": "Feeds: real-pictures (van build = content) · the prep-market product line · the org blueprint (mechanic seat's first big card).", "who": "Commander + the mechanic seat (see WO-recruit-team-mechanic); REFERENCE: the van-life/ mobile-command build world is FULL of proven layouts (skoolie + van build channels) — pick a reference build, don't design from scratch (house-next-door law).", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "the sell-vs-build call (Commander) · the mechanic (next card) · budget line.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-cockpit-and-voice-debriefs", "file": "WO-onboard-cockpit-and-voice-debriefs.md", "title": "build the ONE onboarding cockpit, then voice-walk real people through every funnel and harvest the debriefs", "what": "Two halves, in order: (A) THE ONBOARDING COCKPIT — one URL a new helper lands on that answers Aaron's three questions: how do I get INTO the system, WHAT is the system, WHERE do I go for my path. Today that page does not exist — the funnels (Case Builder, developer, builder network — the only three actually made, all unproven/wishy-washy) have no cockpit to onboard into. v1 = one page: the four doors + the paths table + \"your first task\" per door, rendered from the board. (B) THE VOICE-DEBRIEF PROTOCOL — call real people (Aaron, Johnny, Rachel, Jay, the Squire) and WALK each one through their funnel and their command-center bucket live, on voice, recording a debrief. Every stumble, every \"where do I click,\" every confusion = a card filed on the board. This is the watched-run doctrine (SOP-from-observation) applied to funnels: the funnel is only proven when a cold human walks it while we listen.", "why": "Commander S404c: Aaron — physically present and willing — \"doesn't even know how to get into the system or what the system is or where,\" and Commander had to say \"it's OK, it's all broken, hold on.\" People are arriving faster than the doors are getting built. The widgets are being fixed in parallel; this card is the ORGANIZING half — get organized for the help that's already here. Debrief Fractal Law applies: every close surveys its operators.", "where": "100X_DEPLOYMENT/onboard.html (new page — Gold Standard template, register in MODULE_REGISTRY, three-systems law). Debrief protocol references feedback_sop-from-observation + feedback_debrief-fractal-law (memory).", "who": "Claude + Commander, first credit-refresh session (Commander S404c: \"tomorrow when the credits refresh we really need to hammer through all that\")", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "none blocking — all inputs exist. Commander schedules the three calls.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-physical-builders", "file": "WO-onboard-physical-builders.md", "title": "onboard Aaron/Johnny/Squire into a physical-builder lane + first radio product run", "what": "Turn the willing in-person crew into a working physical-builder lane: a roles table, a bench work area with the board visible, and a FIRST PRODUCT RUN — pick one radio device that already sells online, get its real parts list, order 10, build #1 while the Squire watches, write the SOP from the watched run, Squire builds #2 from the SOP cold.", "why": "Commander S404: \"I got Aaron here he's willing, Johnny's coming tomorrow, we might get a young Squire kid\" — the people are HERE and there is no lane for them. Thousands of parts on the shelf (Pi Zeros, Pi 5s) are unbuilt revenue (ARK memory). The Builder Revolution umbrella brand needs its first physical proof.", "where": "Desktop/1_COMMAND/ONBOARDING_FOUR_PLANS_S404.md Plan 1 (the full plan) · WO-MASTER-builder-revolution.md (the umbrella) · memory project_ark-electronics-kit (the parts).", "who": "Commander (in person, at the bench) + Aaron Surina + Johnny Wicks + the Squire; Claude preps the research packet", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "Commander confirms which device class (Meshtastic assumed from \"radios/software in the radios\" — if it's a different product, the research packet step re-targets, the process is identical). [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "COMMANDER", "project": "★ Builder Revolution (see WO-MASTER-builder-revolution)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-real-pictures-catalog", "file": "WO-real-pictures-catalog.md", "title": "real items, real photos — zero AI-generated product imagery, ever", "what": "A real-photo catalog rule + the first real catalog: every item offered for sale on the platform shows REAL photographs of the REAL item — on the bench, in hand, powered on. NO AI-generated product imagery anywhere in a listing or ad, ever (brand law). First subjects: the first radio units as they're built (unit #1 build tomorrow = the first photo shoot), the ARK kit parts, anything Johnny lists under Exposing Monsters.", "why": "Commander S404n, with Aaron: \"nobody's gonna buy anything off my site until they see real pictures — definitely not putting money in a fake AI-generated ad that looks like a fake product. We have zero agents and zero items for sale with real pictures — we're right at the foundation of ignition with these missing components.\" Trust is the scarce asset; real photos are the cheapest trust we can manufacture, and they're a BYPRODUCT of work already scheduled (the watched build IS the photo op).", "where": "Siblings: WO-onboard-physical-builders (the build being photographed) · THE MONEY page in TOMORROW_PACKET (what's sellable) · WO-builder-economy-spine P3/P4 (what stores will list).", "who": "the bench crew photographs; any agent builds the listings; REFERENCE: any top Etsy/eBay hardware listing (real photos, real hands, real bench — the trust standard to match)", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "which item lists FIRST (radio unit vs an ARK kit vs a Johnny product) — Commander/bench call tomorrow; the card doesn't block on it.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-recruit-team-mechanic", "file": "WO-recruit-team-mechanic.md", "title": "the next seat — an in-person mechanic/engineer for the crew", "what": "One hands-on mechanic/engineer seat filled: a person who owns the physical-systems lane — the van/mobile buildout (WO-mobile-command-buildout), the 3D printer repair, the radio assembly line jigs, the bench infrastructure, eventually the bus. The job CARD (WO form): WHAT they own, first-week tasks (fix the printer · BOM the van · build radio jigs),", "why": "Commander S404am: \"I need to find an engineer... the next guy on our team needs to be a mechanic — recruit an in-person team mechanic.\" Correct read of the gap: the crew has product (Aaron), brand (Johnny), platform (Commander), apprentice (Squire) — nobody owns ATOMS-side infrastructure, and the mobile plan + assembly line both die without it.", "where": "org blueprint OPEN SEATS · siblings: mobile-buildout (their first big card) · onboard-physical-builders (the lane they join).", "who": "Commander recruits (in person, the Squire pattern: found nearby, given a real bench and a real list); REFERENCE: how the Squire got found — proximity + a visible working crew + something real to build. The matching shirts + open garage ARE the recruiting poster.", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER", "next": "none — recruiting can start the day the shirts arrive.", "routed": "COMMANDER", "project": "★ Builder Revolution", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tablet-missing-business-slider", "file": "WO-tablet-missing-business-slider.md", "title": "WO-tablet-missing-business-slider: 3rd cockpit slider (\"My Business\") flashes then vanishes on tablet — hardcoded single-gmail gate rejects the tablet's signed-in identity", "what": "WO-tablet-missing-business-slider: 3rd cockpit slider (\"My Business\") flashes then vanishes on tablet — hardcoded single-gmail gate rejects the tablet's signed-in identity", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "COMMANDER", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tiger-signal-forge-handoff", "file": "WO-tiger-signal-forge-handoff.md", "title": "WO-tiger-signal-forge-handoff: Hand Tiger the music-forge codebase so his AI can build on it", "what": "One package Tiger's AI can read cold that says WHAT the music forge is, WHERE every file lives, WHAT'S DONE, WHAT TO BUILD next, and HOW to send work back — clicked/accepted from inside the builder room, not emailed as a blob.", "why": "REASON: Commander S430 (2026-08-10, this session): \"Tiger wants to work on the signal forge... get everything together... package it up to show his AI what we have... make a whole work order... put it out in a place he can get to it... give him a way to get the work order and what we've done and a way to get it back. This is a good test.\" Tiger is the FIRST real outside builder ready to work; he bounced off the terminal+git+Claude-Code onboarding on a Mac (Dec 2025), so the door for him is BROWSER, not CLI (project_trinity-access-button). PROBLEM: We have a live, valuable music system but it's scattered across ~20 files under two different brand names; no cold reader (human or AI) can pick it up and build without a guided manifest. Without a return channel his work never comes back as a WO. UNLOCKS: The first proven round-trip of the Builder Update Exchange — outbound package → outside AI builds → Builder Update comes back and converts to WOs. Proves the browser-only builder lane.", "where": "repo: github.com/overkor-tek/consciousness-revolution (master) — the music assets are all here. files (the handoff manifest — verified live this session, S430): ENGINE: netlify/functions/song-generate-eleven.mjs (PRIMARY — ElevenLabs Music v2, prompt→MP3→Supabase) netlify/functions/song-generate.mjs (alt — Google Lyria 3 Pro) DATA: netlify/functions/songs-api.mjs (catalog read/publish) netlify/functions/schemas/songs-schema.sql (songs table — one source of truth) netlify/functions/schemas/song-orders-schema.sql MONEY: netlify/functions/song-orders.mjs ($47 custom-song order lifecycle) song-order.html · song-order-thanks.html · my/song-orders.html (intake + host queue) UI: song-forge.html (the generator page — LIVE BETA) song.html · music.html (shareable single + community player) WIDGET: components/widgets/widget-music.js (in-OS music dashboard) METHOD: DNA/OVERKORE_MUSIC_SYSTEM.md (the songwriting-craft / Suno method — CAPTURED, NOT yet built into code = the biggest build opportunity) live URLs: song-forge.html (make a song) · song-order.html?host= ($47 order) · music.html (player) tools: none required of Tiger's AI beyond reading the repo. Generation needs ELEVENLABS_API_KEY (server-side, ours — Tiger never handles keys). sign-in needed: Build Guild entry + signed contributor agreement (see the room click-path below).", "who": "Tiger (Brandon McBride, handsonmovers303@gmail.com) + his AI · assembled by CP3", "status": "blocked", "claimer": "", "lane_raw": "COMMANDER-TODAY", "next": "- NAMING DECISION (see OPEN-ISSUES) — blocks the card title + which page Tiger lands on. - Guest/comment claim path so Tiger can ACCEPT without a full account (dev-board C4 cliff). - Bucket-2 agreement gate (PR #1108) merged so the signature actually enforces. - A decided file-delivery location (repo browse vs vault zip).", "routed": "COMMANDER", "project": "builder-update-exchange (first real cold-builder handoff)", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false } ], "CHEAP-CLOUD-AGENT": [ { "id": "WO-application-module", "file": "WO-application-module.md", "title": "WO-application-module — ONE application system: Build Guild intake first, sellable hiring module after", "what": "The optimized application flow: form (who you are, what you build, links, why) → review queue with accept/deny + reason → accepted applicants land in the onboarding funnel with the `developer` role granted. Character-forge alignment: answers map to the ladder (what level they enter at). Deny half without drama — \"nothing given, only earned.\"", "why": "Commander (S433): \"we need to get to the point where we're taking applications into the build guild and denying the lower half... that way we develop a module for applications for all these businesses that are hiring — we'll already have one.\" Same recursive-products play as time cards: use it ourselves, then sell it.", "where": "builds ON the existing pieces — builder agreement flow + ONE-GATE roles + character-ladder filter (access EARNED doctrine). The trusted first cohort BYPASSES this (BG-1 note: no heavy vetting for known people) — this is for UNKNOWNS arriving from the tour/cards/socials.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-walkthrough-coach", "file": "WO-araya-walkthrough-coach.md", "title": "ARAYA coaches live verbal walkthroughs — every caller becomes a Commander-grade bug harvest", "what": "A WALKTHROUGH MODE for ARAYA (voice-first — phone or console voice): the user calls and says \"walk me through my console\" (or she offers it when they sound lost). She then RUNS the protocol Commander does naturally but nobody else will do unprompted: 1. SETUP: \"Open your console on another device — I'll wait. Tell me when you see the top bar with your business name.\" 2. PER-TILE LOOP (driven by the compiled interface map — she iterates the blueprint's widgets in grid order): \"Tap [tile]. Narrate out loud: what do you see? Tap the things inside it. What did you EXPECT to happen? What actually happened? What feels confusing?\" 3. CAPTURE: every friction logged as a DISCRETE bug the moment it's spoken (one at a time — Commander's standing law), tagged {widget_id, expected, actual, device, quote}. Rail: the existing bug/lead capture the receptionist already uses (Johnny's 10-minute-hangup bug arrived exactly this way, unprompted, 7/31) — structured, not a transcript dump. 4. WRAP: she reads back the count (\"we caught 9 — Darrick's team gets these tonight\"), thanks them, and the batch lands in the friction list of WO-tune-tenant-interfaces + the bug board.", "why": "The platform has no scalable way to harvest Commander-grade bug reports. Tenants stumble through consoles silently; friction is invisible. ARAYA walkthrough mode turns every caller into a narrating observer — one 20-minute coached call yields more actionable bugs than weeks of passive monitoring. DO: 1) Locate the call-duration cap in receptionist/twilio config and raise it to 30min for walkthrough-flagged calls. 2) In araya-chat.mjs tenant path, generate a WALKTHROUGH_MODE prompt section by reading DNA/BLUEPRINT/INTERFACES/{tenant}.json (tile list, expected behaviors). 3) Add walkthrough trigger phrases to ElevenLabs PERSONA_OVERRIDES (\"want a guided tour?\" offer when caller sounds lost). 4) Extend the postcall/lead capture rail: add walkthrough=true flag and per-item schema {widget_id, expected, actual, device, quote, timestamp}. 5) Wire wrap report to SMS Commander + write to WO-tune-tenant-interfaces friction list + bug board.", "where": "depends on (build AFTER): the ARAYA map injection (blueprint step 4 — she must know the tiles before she can walk them). Files then: araya-chat.mjs tenant path (walkthrough mode prompt section generated from DNA/BLUEPRINT/INTERFACES/*.json) · ElevenLabs personas (PERSONA_OVERRIDES + tenant agents: add the \"want a guided tour?\" offer + walkthrough script) · capture: the postcall/lead rail with a walkthrough tag + per-item schema · ⚠️ the 10-minute call cap (Johnny's first bug!) must be raised/handled for walkthrough calls or she hangs up mid-harvest — fix that FIRST, it's already on the board.", "who": "Claude builds the persona + capture rail; Johnny + Rachel are the first coached callers; Commander's own narrated walkthroughs = the training reference", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "- REFERENCE: See DNA/WIDGET_FACTORY.md — Widget WOs should reference WIDGET_FACTORY.md", "routed": "CHEAP-CLOUD-AGENT", "project": "araya-agency (PRIMARY) · also touches: tune-tenant-interfaces (WO 0.2) + interface-blueprint (S395) + receptionist product", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-widget-doors", "file": "WO-araya-widget-doors.md", "title": "ARAYA flips screens by voice — every widget door taught, tested, and green on the daily eval", "what": "ARAYA reliably opens/switches any widget in the Pulse shell on request — typed or voice: \"pop out my to-dos,\" \"show me the projects board,\" \"open my leads.\" Screen-flipping = emitting the right [WIDGET:x] marker for every registered widget, including the NEW S392 widgets (projects atlas, ranked to-dos), and staying green on the daily eval harness. PRIORITY (Commander S403): teach the doors in THIS ORDER — (1) the CASE-BUILDER widgets FIRST (caseboard / casetimeline / case — the fleet hardened this weekend), then (2) the Commander-7 dashboard widgets. \"Open the widgets = get ARAYA to actually use them.\" She can't drive the case fleet by voice yet, and that's the highest-value cockpit unlock — it turns the mountain of built widgets into USABLE ones (the S337 law: a widget isn't done until the operator can drive it).", "why": "Commander (S392c): \"Get ARAYA using widgets to where she can flip screens — that should be pretty high on the to-do list.\" It's literally step 1 of the cockpit build order, and the cockpit's whole premise (widgets, never new pages — S337) only works if the operator can drive it. TODAY'S TEST RECEIPT (araya_eval_latest.json 2026-07-30 14:45): 26/28 pass, 0 confabulations, FAILING: `belt_open_tasks` + `wo_file_bug` — the tasks-door scenario is red RIGHT NOW. This WO = fix the red doors + teach the missing ones. WHERE (all verified on origin/master 2026-07-30 — NOTE: the local 100X checkout is 20+ commits behind; grep origin/master, not the working tree): repo: 100X_DEPLOYMENT (worktree + PR per THE MERGE LAW) - netlify/functions/araya-chat.mjs — THE ROUTER: emits [WIDGET:] markers (the flip mechanism) - components/widgets/widget-projects.js + widget-todos.js — the S392 doors (PR #649, live on prod); entry points WidgetProjects.query() / WidgetTodos.top() - my/pulse.html — the ONE shell that hosts/renders the widgets - .consciousness/ARAYA_ROUTING_HARNESS.py — 17+ golden scenarios incl. the TOOLBELT widget-open regression block (WIDGET:leads, WIDGET:links proven S358); daily 7 AM schtask - DNA/ARAYA_UI_MAP.md (before changing any UI) · reference_elevenlabs-agent-config memory (the voice side) sign-in needed: none to build; prod deploy via the gated ratchet", "where": "", "who": "Claude/agent running the S337 teach→tune→watch→fix→record round; Commander drives the real voice test", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "the belt_open_tasks failure diagnosis (first task — read the harness's failure detail in ops_reports) · whether voice STT→router path needs its own scenario class (confirm during TUNE) · who to talk to: Commander (the only real user today); ElevenLabs agent config is in the config-bible memory if the voice layer needs touching. || [2026-08-02 S394 — LEVELED TO L5] Added CLAIMABLE block + DATA section with exact file paths and commands + DO checklist with ordered steps + DONE= checklist with empty boxes to fill on completion. Stranger unit now has everything needed to pick this up and run.", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA agency + cockpit screen glue (blueprint build-order step 1)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-builder-agent-delegation", "file": "WO-builder-agent-delegation.md", "title": "WO-builder-agent-delegation — builders send their AI into the Guild as their delegate", "what": "Make a builder's AI a first-class delegate: scoped credentials tied to the HUMAN's account, so their agent can read the board, claim a card, do the work through the existing rails (code mirror, component contracts, PR flow), and submit — with every action attributed \"agent-of-\" and XP/credit flowing to the human. The human signs the CLA and stays accountable; the agent is hands, not identity.", "why": "Commander (S433): \"are people able to just send their AI into the build guild instead of going there themselves???\" Half exists BY DESIGN: the code mirror + llms.txt/agents.json were built for external AI consumption (S431), the board JSON is public machine-readable, WOs are written to the agents-are-humans cold-start standard, and our OWN fleet already proves agents close cards nightly. The missing half is the DOOR: delegated auth + attribution + guardrails. Whoever ships this first owns \"bring your own AI workforce\" — it multiplies every builder we onboard.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-invite-security-audit", "file": "WO-builder-invite-security-audit.md", "title": "WO-builder-invite-security-audit — before the trickle opens: audit EVERYTHING an invited builder can see", "what": "A full security walk of the builder surface, from the outside in, as THREE personas: (1) anonymous visitor, (2) signed-in builder (?builder=1 + dev-board + claimed card), (3) GitHub repo collaborator (Brandon's actual grant). For each surface, answer: what trade secrets, credentials, personal data, or business strategy can this persona reach?", "why": "Commander (S433): \"check over the whole system from a security standpoint — make sure when we invite people to build with us we're not giving away any crazy trade secrets. After we established communications we got to establish security.\" The trickle plan (~130 leads behind the first 4) multiplies whatever exposure exists TODAY.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-builder-mesh-radios", "file": "WO-builder-mesh-radios.md", "title": "WO-builder-mesh-radios — every builder becomes a node: pick THE radio + mesh stack", "what": "Builders walk around with radios; every builder is a node on OUR mesh — presence, messages, and eventually telemetry, off-grid capable. This WO picks the ONE stack and proves it with two nodes.", "why": "Commander (S433 recording): \"all the builders need to be walking around with radios. Every builder becomes a node... we need all sorts of radios, but we need one specific.\" Sovereign comms is a backbone (no-single-capture doctrine) and the gadget line feeds the device store.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-commander-daily-page", "file": "WO-commander-daily-page.md", "title": "the Full Focus daily page — bold ONE THING + Big 3 + appointments + day log, one view, screen and paper", "what": "Unify the EXISTING S364 planner stack into Commander's actual daily page, laid out like the physical Free to Focus planner: THE ONE THING bold at top (usually a system change — \"sell the vehicle\" class), two lesser Big-3 slots under it, today's appointments below, and a DAY LOG pane — the running blog of the day (\"Joe called, wants paint colors\") whose lines get harvested into to-dos at wrap and recycled or deprioritized by the morning rollover.", "why": "Commander (S392c): \"this system tuned into Commander's widgets and cockpit — a practical version of the Free to Focus planner.\" GREP-BEFORE-BUILD RESULT (2026-07-30, receipts read): most of this ALREADY RUNS — do not rebuild: ✅ PLANNER_ROLLOVER.py (schtask 6:45 AM): unfinished→today, one_thing keeps the crown, big3 weight-capped at 3, morning Big-3 SMS via the 855 ✅ PLANNER_WRAP.py (schtask 9 PM): day/week/month/quarter/year wraps — \"Free to Focus ritual cadence\" verbatim; quarterly Big 3 lives in HORIZONS.md ✅ PLANNER_MIRROR.py + a planner widget (rollover header references the widget's big3 cap) The GAPS this WO closes: (a) no first-class DAY-LOG capture surface (today: INBOX.md + texts, harvested only at bootdown), (b) no ONE PAGE uniting Big 3 + appointments + log (calendar widget is separate; MondayPrint prints weekly, not daily), (c) day-log lines don't feed the WO store harvest.", "where": "repo: home monorepo files to read first: - .consciousness/PLANNER_ROLLOVER.py + PLANNER_WRAP.py + PLANNER_MIRROR.py (the engines — READ before touching) - Desktop/1_COMMAND/HORIZONS.md (quarterly Big 3) · the planner/To-Dos/calendar widgets in the Pulse shell - .consciousness/MONDAY_PRINT script + SNAPSHOT facts cache (silent-print rail: Tools/SumatraPDF -print-to-default -silent) - Desktop/1_COMMAND/WORK_ORDER_ARCHITECTURE_S392.md §2 (the harvest flow the log feeds) sign-in needed: Supabase service key (planner tables); none for print", "who": "Claude/agent with planner recon done; Commander supplies planner photos + drives the real-day test", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "- REFERENCE: See ONE_THING + Big-3 + appointments + blank day-log lines (8-10 lines for handwriting) — rate PDF → SumatraPDF -print-to-default -silent # Template: ONE_THING + Big-3 + appointments + blank day-log lines (8-10 lines for handwriting) **ROW:** parent=T11 · kind=page · avenue=agent-fleet · level=L3 · tier=C · verdict=live (blocked: Commander planner photos required) · wave=S462", "routed": "CHEAP-CLOUD-AGENT", "project": "Commander cockpit (screens 1", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-cyberdeck-forge", "file": "WO-cyberdeck-forge.md", "title": "WO-cyberdeck-forge — turn the parts pile into the first builder cyberdeck (superhero device #1)", "what": "First cyberdeck from the existing parts pile (3 keyboards, radio parts, Raspberry Pis): a portable builder terminal — Pi + keyboard + screen + battery + mesh radio node (see WO-builder-mesh-radios) in one carryable unit.", "why": "Commander (S433): \"we're going to turn these into some superhero type devices... make some cyberdecks.\" The deck is the physical face of the gadget line — tour demo unit, store product photo, and the builder node carrier.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-file-sharing", "file": "WO-file-sharing.md", "title": "builders + crew can share files with each other, not just Commander's private vault", "what": "A shared file space for the TEAM/crew zone — the middle of the Galactic Cruiser. Today the vault (just got going, S391 PR #635) is PRIVATE (owner-scoped). This adds the missing \"share a file with each other\" that every collaboration tool has and we don't: a builder attaches a file to a work order / project card / DM and the right people (not the public, not everyone) can see it. The FILES slot of the work-order card, made real for more than one person.", "why": "Commander (S392): \"we don't have anywhere to share files with each other — just barely got the file area going.\" The whole team zone (Johnny, Rachel, incoming builders) can't hand each other a document. Slack/Lark/Notion all have this as table stakes (channel file shares); it's the one Slack component we're most clearly missing on the TEAM side (comms we have via Discord; the private vault we have; team file-share is the gap). Blocks real collaboration on shared work orders.", "where": "repo: github.com/overkor-tek/consciousness-revolution (the 100X deploy repo — all files below live THERE, fetchable by fork; \"home monorepo\" was wrong, fixed S393) files to read first: - netlify/functions/vault-api.mjs + evidence-upload.mjs (the private vault — extend, don't fork) - my/vault.html + doc-vault.html (the UI; S391 fixed uploads) - the work-order card FILES slot (WO-TEMPLATE-painting.md) — files attach BY the never-change ID (WO-file-indexing-ingest) - RLS reference: DNA security notes on case isolation (team-scope is a NEW visibility tier — design the RLS carefully) sign-in needed: Forge Passport (team members); Supabase service key for the function", "who": "developer; Commander confirms who-can-see-whose-files", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "the TEAM-SCOPE definition (what makes two users \"on the same team/project\" — a shared project id? a crew roster table?) is a data-model decision. Confirm before building the RLS. Pairs with WO-file-indexing-ingest (files share by stable ID). || [2026-07-31 S393 STRANGER-TEST: PARTIAL] Fixed the killer defect: WHERE said \"home monorepo\" (a", "routed": "CHEAP-CLOUD-AGENT", "project": "THE PEOPLE (screen 7)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-gadget-device-store", "file": "WO-gadget-device-store.md", "title": "WO-gadget-device-store — ONE store aggregating maker devices (cyberdecks/radios/gadgets); free test units = the cheat", "what": "One storefront/catalog collecting the maker-device world in one place — cyberdecks, mesh radios, off-grid comms gadgets — curated with honest reviews. Path A: affiliate/curation catalog (day one). Path B: wholesale/resell. Path C: our own devices (WO-cyberdeck-forge output). All three can coexist.", "why": "Commander (S433): \"everybody making devices online — we need to collect them all in one spot and have a store that sells all the kinds of devices. And then they would be giving us devices to test for free, for us to advertise — that's probably the ultimate cheat.\" Review units + tour demos + content engine = the flywheel: devices arrive free → filmed on tour → store sells them → makers send more.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-hud-dock-single-source", "file": "WO-hud-dock-single-source.md", "title": "pulse.html should READ the shared HUD_DOORS, not fork its own copy", "what": "`my/pulse.html` defines its own `window.ARAYA_SHELL_NAV` array that fully overrides `components/cr-chrome-v2.js`'s shared `HUD_DOORS`/`hudSkin()` default dock. It has already silently drifted from the shared 5-door set (Report was added there S431, and Comms/Music landed there separately from the shared file S432) — meaning a future shared-dock change again won't reach pulse.html without a second manual edit. Refactor pulse.html to build its NAV array from `HUD_DOORS` (import the id list + any pulse-only extras like 'bug') instead of hand-duplicating every door's icon/label/action.", "why": "Found live S432 (debrief, claude-cp3): changing the shared dock (Comms+Music swap) required a SECOND edit to pulse.html's own array to actually take effect there — the two silently diverged once already (Report) and would again. One source removes the class of bug.", "where": "my/pulse.html (`window.ARAYA_SHELL_NAV`, ~line 51) · components/cr-chrome-v2.js (`HUD_DOORS`, `hudSkin()`, ~line 1510-1572).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "HUD", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-invite-francis-missions", "file": "WO-invite-francis-missions.md", "title": "invite Francis Hornby in (he's dying to be involved) + seed him 2-3 starter missions in the start menu", "what": "Commander S415: \"Francis is dying to be involved... not sure what mission to give him but we should invite him and give him some missions in the start menu at some point.\" Francis Hornby (GateWalker co-builder) emailed Jul 8 2026: \"I would be honoured to be involved.\" Contact: frankhornby6@gmail.com · WhatsApp +490178527565. Invite him + seed 2-3 starter missions on his start menu.", "why": "An eager, capable ally is the cheapest fuel there is — but only if he lands with a clear first mission (not a blank start menu). Seed-before-sell / give a concrete first job.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "people", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-living-tree-build-display", "file": "WO-living-tree-build-display.md", "title": "the manifesto chart as a real-time build display - watch nodes light up as they're done", "what": "Turn the manifesto chart / NODES.json tree into a LIVE build display: each WO-node lights up as it goes open->claimed->done; benchmarks (see WO-fractal-benchmarking-harness) color the nodes by health. People WATCH the tree get built - contributors see their piece land; everyone watches the whole grow.", "why": "The manifesto chart (system-map.html) is a passive poster: contributors cannot see their work land live, and there is no control surface to operate nodes (toggle on/off, wire feeds, adjust parameters). This kills engagement and prevents crowdsourced contributions from feeling real. DO: Modify system-map.html to poll WORK_ORDERS_BOARD.json every 5s, map each WO's status to its corresponding NODES.json node, and render: (a) live status badges (open/claimed/done) on each node, (b) benchmark-based color coding via CSS classes from NODES.json grades, (c) a control panel overlay allowing authorized users to toggle node visibility and wire RSS feeds per node.", "where": "system-map.html (L6 manifesto chart) reads NODES.json - add live status + benchmark coloring + WO-node light-up. Ties to WO-multi-machine-kanban (the board) + WO-chat-doable-crowdsource (contributors).", "who": "CP1 / a widget builder", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "depends on WO-fractal-benchmarking-harness (the node grades) + the live board wiring. || [2026-08-01 S398, Commander] UPGRADE the aim from \"watch it\" -> \"OPERATE it\" (n8n-style). Commander:", "routed": "CHEAP-CLOUD-AGENT", "project": "visibility", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-node-profile-drilldown", "file": "WO-node-profile-drilldown.md", "title": "clicking any node opens its full profile — what it is, what it was made for, its CTAs, its mechanics log (last/now/next), a screenshot, and its beta level", "what": "Turn the manifesto chart's slide-out panel from a short list into the full NODE PROFILE Commander specced: click a node and see (1) what it is + what it was made for, (2) the calls-to-action on it, (3) its mechanics log = what happened last / what's happening now / future to-dos as work orders with directions + data attached, (4) a picture of the surface (screenshot when it was made), (5) its beta-test level. \"You basically click into it and it shows you everything.\" The node profile is the SAME recursive form as the project profile and the work order — one shape at three zoom levels.", "why": "Data is scattered across MECHANICS_LOG_*.md, FLIGHT_LOG.md, WORK_ORDERS_BOARD.json, and UNKNOWN/NEEDS-RESEARCH analytics source. When a human or agent needs to understand \"what is this node, what does it do, what's its state, what's next,\" they must grep across 4+ files with no single entry point. The map shows 347 nodes but clicking one reveals only a 2-line stub. The problem: context collapse — every node exists in isolation, hiding its purpose, history, and next action. This kills velocity: decisions require manual archaeology instead of one click.", "where": "repo: home monorepo files to read first: - Desktop/1_COMMAND/MANIFESTO_SHAPE.html (the chart + its openPanel() — extend the node model + panel render) - DNA/MECHANICS_LOG_*.md (the per-node history feed — \"what happened to it\") - DNA/BLUEPRINT/NODES.json + system-map.html (the 347-node technical map to reconcile with; don't duplicate) - Desktop/1_COMMAND/WORK_ORDER_STANDARD.md (the \"future to-dos with directions + data\" = the WO form, attached per node) - analytics source: (MISSING — see below) sign-in needed: none to prototype; whatever the analytics feed needs to read traffic", "who": "developer or agent; Commander confirms the profile field list once", "status": "open", "claimer": "", "lane_raw": "MACHINE-2", "next": "the ANALYTICS FEED — \"the traffic of people who clicked through\" — needs a source. Is there a page-analytics store already (check for a Plausible/GA hook or a Supabase page_views table) or is that its own WO? Determine before building section 3's analytics line. The screenshot auto-capture hook does not exist yet — may split into its own small WO.", "routed": "CHEAP-CLOUD-AGENT", "project": "THE MAP (screen 4) leveled up", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-onboard-funnel-router", "file": "WO-onboard-funnel-router.md", "title": "the switchboard — every inbound human gets routed to a lane + one action, never a dead end", "what": "A routing layer on the front door: ARAYA (web chat first; 855 line + email-in later) asks ~3 sorting questions and tags every new contact into ONE lane — BUILDER (physical) / DEV (technical) / CASE (needs help) / SUPPORTER (everyone else) — then delivers that lane's day-1 action instead of dumping them into the interface mess.", "why": "Commander S404: \"thousands of people have contacted us trying to help... Commander can't even get anybody in to help because it's just such a mess.\" The four onboarding plans exist (ONBOARDING_FOUR_PLANS_S404.md) but nothing SORTS people into them. The switchboard vision: ARAYA OS as a telephone system — people ding in and get routed.", "where": "Plan 4 in ONBOARDING_FOUR_PLANS_S404.md · WO-araya-v2-pulse-landing-chat (the front door this rides on) · WO-chat-doable-crowdsource (the SUPPORTER/DEV payload) · WO-idea-intake-router (adjacent — that routes IDEAS, this routes PEOPLE; share mechanics if it helps, don't merge).", "who": "any agent comfortable with ARAYA prompts + the contacts API; ~1 session for v1 (web chat only)", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "none blocking v1 — the front-door chat and contacts API are live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "onboarding", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-per-agent-korpak-work-areas", "file": "WO-per-agent-korpak-work-areas.md", "title": "Build role-scoped cockpit work areas for each agent terminal", "what": "Each AGENT terminal (T1/T2/headless workers) gets its own role-scoped cockpit + holding pen for captured to-dos — the same korpak model as human builders, applied to Claude terminals. Replaces dumping to-dos in the desk.", "why": "REASON: S392 Commander directive: \"you are T1 terminal, go into a clean work area\" · PROBLEM: Agent to-dos scatter across FIX_CLIPBOARD, palettes, and session files with no persistent work area · UNLOCKS: Agent self-management, work continuity across sessions, reduced coordination overhead DO: 1. Design agent korpak schema (T1 supervisor, T2 specialist, worker pools) 2. Extend Pulse korpak system to support agent identities 3. Build agent-scoped widgets (claim board, session log, parked chunks) 4. Wire to existing WINDOW_BUS palette system 5. Document agent onboarding to work-area DATA: INPUT: COCKPIT_BLUEPRINT_S392.md, existing korpak implementation · OUTPUT: Agent work-area system · SCHEMA: agent_korpaks table or JSON · INDEX: AGENT_WORK_AREAS.md", "where": "repo: 100X_DEPLOYMENT + home monorepo · files: my/pulse.html, WINDOW_BUS system · tools: node, Supabase", "who": "developer with Pulse widget + korpak system knowledge", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "Full korpak technical spec (read existing implementation)", "routed": "CHEAP-CLOUD-AGENT", "project": "cockpit", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-phone-answering-cockpit", "file": "WO-phone-answering-cockpit.md", "title": "WO-phone-answering-cockpit — the SaaS phone loop: ding → headset → human closes the sale", "what": "The human-in-the-loop sales cockpit: when a store visitor or caller \"dings in\" (store chat, callback request, or phone line), anyone on duty with a headset gets the alert, answers, and can close the sale. Log every ding: answered-by, outcome, revenue. This is the \"tune the cockpit, then step out of it\" pattern — Commander runs it first, then others earn money answering.", "why": "Commander (S433): \"a store that converts probably has something to do with us being there to answer the phone... anytime somebody dings in it could be to close a sale... at some point this turns into a phone answering service where people make money answering phones and closing sales.\" (Tiger's tax-lien + Aaron's DICOM = future tenants of the same cockpit.) The 10%-human rule: this IS the 10% next to the AI.", "where": "existing rails — ARAYA receptionist + Twilio line + commander-alert SMS + the store pages (offerings consolidation). v1 = wire, don't build: ding → SMS/push to the on-duty person + a simple duty-roster toggle + an outcomes log table.", "who": "", "status": "open", "claimer": "", "lane_raw": "NOW", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-phone-bug-reporting", "file": "WO-phone-bug-reporting.md", "title": "make the 855 phone agent actually FILE bugs (text + voice) → visible on the bug board", "what": "make the 855 phone agent actually FILE bugs (text + voice) → visible on the bug board", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "confirm WHICH function is the live 855 SMS webhook (araya-phone vs sms-webhook) before editing — a quick test-POST to each tells us; avoid editing the wrong handler. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA phone", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-social-reels-chatroom", "file": "WO-social-reels-chatroom.md", "title": "turn the chat-room area into a social surface — a real FEED + a REELS (short-video) section", "what": "The chat-room area is channel-based text chat today (team-comms.html) plus community Rooms (widget-rooms.js).", "why": "REASON: Commander ask — \"turn the whole chat-room area into a social-media-style surface: a real FEED section + a REELS (short-video) section. Widget or mode, never a new page.\" (this card's source ask, 2026-08-06.) Pairs with the standing [Sovereign Social Fan-Out] project (post-once → broadcast). PROBLEM: the community area is 1:1/room chat only — there is no place to BROADCAST a post to everyone and no short-video format at all. The team/community can talk in a room but cannot scroll a feed or watch reels, so the surface feels like a chat app, not a social platform. UNLOCKS: a social home inside ARAYA OS — a feed to post-once-and-broadcast and a reels lane for short video, the front-end that the Sovereign Social Fan-Out broadcast engine can eventually publish INTO.", "where": "repo: 100X_DEPLOYMENT, master (worktree per LAW #4) files to READ FIRST (do not guess the shape): - team-comms.html — the chat-room area (channels sidebar + message list). A FEED could be a new sidebar section / mode alongside the existing channels; READ how channels render (loadChannels, currentChannel) before adding a mode. - components/widgets/widget-rooms.js — the community Rooms widget (renderCard/renderExpanded, act('join'), backed by rooms-api.mjs, multi-tenant + JWT-scoped). Closest existing pattern for a new social widget: same contract shape (BLUEPRINT, dataFeed/dataSelect, renderCard/renderExpanded, act). - components/widgets/widget-comms.js — the Comms sheet; shows the widget CONTRACT + live-poll + demo/401 gate pattern to CLONE (authHeaders, loadComms, CONTRACT). A feed widget should mirror this shape. - components/widgets/widget-music.js — existing MEDIA widget (audio player). READ for how media is fetched + played; a reels player is the video analog. - components/widgets/widget-files.js — existing file surface; READ to learn whether an upload/storage path already exists that reels could reuse (see MISSING). - DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json — where a new widget's commands get DECLARED (same as the 'rooms'/'comms' entries) so ARAYA can invoke it. tools: node (--check .js), git worktree, netlify (deploy GATED). sign-in: Supabase JWT (same gate as rooms/comms).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "a social-media-style surface layered on that same area — (1) a real FEED section (a broadcast timeline of posts, newest-first, likes/comments) and (2) a REELS section (short vertical videos you swipe). Add both as a widget/mode inside the existing area — NEVER a new page.", "routed": "CHEAP-CLOUD-AGENT", "project": "Sovereign Social Fan-Out", "priority": "P3", "tier": "C", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-supply-lesson-add-production-watchdog-widget-create-a-20260806-052842", "file": "WO-supply-lesson-add-production-watchdog-widget-create-a-20260806-052842.md", "title": "**Add Production Watchdog Widget** — Create a daily automation that queries our", "what": "Implement: **Add Production Watchdog Widget** — Create a daily automation that queries our production DB for key customer events, summarizes them in JSON, and displays a \"Yesterday in Production\" widget in the dashboard with deep-links to actual UI states. This allows the human operator to spot \"that's weird\" anomalies via the \"brain\" interface that automated tests miss.", "why": "Derived from YouTube lesson vJEy3nP2_C8 — strategic implementation of external learnings into our system", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "supply-engine auto-generated", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842", "file": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842.md", "title": "**Implement the 25-Minute Decision Dashboard** — Change the brain/widget notific", "what": "Implement: **Implement the 25-Minute Decision Dashboard** — Change the brain/widget notification system from real-time alerts to batched \"decision windows\" every 25 minutes. Surface only high-stakes decisions (production deploys, architecture changes) during these windows; let low-stakes bug fixes auto-merge to prevent operator burnout while maintaining velocity (target 22-25 PRs/day).", "why": "Derived from YouTube lesson vJEy3nP2_C8 — strategic implementation of external learnings into our system", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "supply-engine auto-generated", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tenant-araya-walkthrough", "file": "WO-tenant-araya-walkthrough.md", "title": "program each tenant's ARAYA to WALK THE USER through their console", "what": "Program the tenant console's ARAYA so it can guide a tenant (Johnny, Rachel, and every future one) through their own console — what the 8 buttons do (Start/Calls/Leads/Comms/Orders/Contacts/ Booking/MyPage), what to test, and the HONEST current state (early version, ARAYA can't drive the widgets yet, some screens are shells). So the AI co-pilots them when Commander isn't on the phone.", "why": "", "where": "tenant console ARAYA at `https://100xbuilder.io/tenant/` + the walkthrough script (use template above or extract from tonight's chat). Pairs with WO-tenant-welcome-message (Start-menu widget) but not blocked by it.", "who": "the tenant-console/ARAYA window (has the console + ARAYA context model)", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "NONE — this work order is L5 CLAIMABLE. Discovery paths are specified in DO step 2. Template script is provided in CLAIMABLE section. If discovery fails (storage location not found), escalate to Commander with search output.", "routed": "CHEAP-CLOUD-AGENT", "project": "ARAYA", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-tune-tenant-interfaces", "file": "WO-tune-tenant-interfaces.md", "title": "take everything we've learned and TUNE the live believers' interfaces — Rachel's and Johnny's, until a real session needs zero Commander hand-holding", "what": "Apply the whole S392-era stack (cr-frame chrome, korpaks, stage-unlock, widget doors, receptionist persona tuning) to the two REAL tenants we already have: **Johnny Wicks** (already testing the receptionist; stage-unlock pilot; tip-line persona bug precedent — it once answered as Preble Pressure Washing) and **Rachel** (Primordial Flow / ArtWorks Land Lab, comped founder). Their interfaces get dialed until they're smooth for THEM — this is the funnel repair executed on believers instead of imagined for strangers.", "why": "Commander (S392c): \"we need to take everything we've learned here and tune the interface for Rachel — we got to tune Johnny's.\" The GTM blueprint's whole premise is seeds-over- strangers; a seeded believer on a messy interface churns exactly like a stranger does, just slower and more politely. These two tuned interfaces also become the template every later tenant clones (the ∞ of the fractal — copy a korpak).", "where": "repo: 100X_DEPLOYMENT (worktree + PR per MERGE LAW) files to read first: **`Desktop/1_COMMAND/ONBOARD_JOHNNY/JOHNNY_WICKS_DNA.md` — THE one spot for Johnny (S395 consolidation: catalog, live surfaces, phone persona, cockpit punch list, all IDs, 19 open items, pointer map — start here, everything else is one hop)** · memory project_johnny-wicks.md + user_rachel-primordialflow.md + project_araya-receptionist-tuning.md · DNA/WIDGET_FACTORY.md (the one door) · the korpak keying mechanism (shipped S381) · johnny-wicks tenant pages + stage-unlock module · Rachel's ArtWorks/Land Lab surfaces sign-in needed: tenant-side test accounts; ElevenLabs config for persona checks", "who": "Claude/agent builds + tunes; Johnny and Rachel verify live (they ARE the receipt); Commander introduces the session", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "Rachel's current surface inventory (what she actually uses today — pull from her memory file + ask her) · MORE of Johnny's friction in his words (first item captured above) · scheduling both verification sessions (Commander intro text, one line each). NOTE: Step 3's test call doubles as the outstanding receipt for the S391 PERSONA_OVERRIDES pressure-washing fix (PR #639) — deployed, never call-verified. One call closes both.", "routed": "CHEAP-CLOUD-AGENT", "project": "tenant-experience (PRIMARY) · also touches: first-believers (GTM Phase 0) + AI-receptionist + korpaks + stage-unlock — the many-to-many law's first real card (WORK_ORDER_STANDARD §5)", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-v1-ratchet-opsec-timeout", "file": "WO-v1-ratchet-opsec-timeout.md", "title": "WO-v1-ratchet-opsec-timeout — OPSEC scan in v1-ratchet takes >5 min and times out", "what": "WO-v1-ratchet-opsec-timeout — OPSEC scan in v1-ratchet takes >5 min and times out", "why": "While building WO-builder-green-projects, `v1-ratchet.py --regen` timed out twice: first at 120s, then at 300s, both dying inside `check_opsec()` which calls `opsec-scan.py --json`. The PAGE_LEDGER step completed fine (227 pages), but the OPSEC scan is so slow it blocks the ratchet from finishing. This means builders cannot verify their PRs pass the quality gate before filing, which breaks the \"self-heals\" sprint goal. The opsec scan likely recurses over the entire repo including node_modules or performs expensive regex over large files. DO: 1. Profile `opsec-scan.py` to find the slow path (likely recursive scanning or large-file regex). 2. Add scoped scanning: only check files that changed in the PR, not the entire repo. 3. Add caching: skip files that haven't changed since last scan. 4. Add a fast-mode flag `--quick` for local dev that skips deep entropy analysis. 5. Ensure `v1-ratchet.py` completes in <60s for a typical PR (<20 files changed).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "PUBLIC", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-json-role-filtering", "file": "WO-widget-json-role-filtering.md", "title": "gate the todos/projects/board widget JSON by role — stop shipping the whole store to every viewer", "what": "`widget-todos.js`, `widget-projects.js`, and `widget-workdesk.js` all fetch ONE generated JSON (`PROJECT_REGISTRY.json` / `WORK_ORDERS_BOARD.json`) with no server-side role filter — a DEVELOPER-tier viewer currently sees the exact same lanes/cards/seats as COMMANDER. This WO makes the generators (or a thin serving layer) filter by the signed-in role before the JSON leaves the server, not just hide-in-the-UI (client-side hiding is not access control).", "why": "`widget-workdesk.js`'s own header comment names this explicitly: \"no korpak-based lane filtering yet: a DEVELOPER seat sees every lane the same as COMMANDER today, because none of the shipped widgets in this fleet gate their JSON server-side yet (todos/projects/board are the same).\" That comment has claimed since S392/S394 that this was \"filed as a follow-up WO, not silently shipped as done\" — checked S395: no such WO existed. This WO makes that claim true. Commander also named the Team/Commander view toggle on the board widget as a stand-in (\"YES filter by role, and the filter IS the Commander-vs-team UX\" — WO-board-ux-widget) but that toggle is currently a plain UI switch anyone can click, not a role check — it doesn't close this gap, it just proved the UX shape.", "where": "repo: 100X_DEPLOYMENT (worktree + PR + same-session merge, MERGE LAW) files to read first: `components/cr-page-gate.js` (the live role source — reuse it, don't invent a second identity check) · `DNA/PROJECTS/build_project_registry_json.py` + `DNA/generate_work_orders_board.py` (the two generators that would need a role param) · `DNA/MECHANICS_LOG_IDENTITY.md` (once WO-publish-role-ladder-mapping lands, the canonical role vocabulary to filter against) · the three widget files' HONEST GAPS comments sign-in needed: a signed-in DEVELOPER-tier test account to prove the filter actually hides something (not just COMMANDER, who should see everything)", "who": "unclaimed — any agent with `components/cr-page-gate.js` + the three widget generators open", "status": "blocked", "claimer": "", "lane_raw": "MACHINE-2", "next": "the exact role→visible-lane mapping (which lanes/cards a DEVELOPER should NOT see) — Commander decision, not a Claude default; whether role changes need to take effect without a rebuild (picks HOW step 2's option a vs b).", "routed": "CHEAP-CLOUD-AGENT", "project": "identity", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-widget-out-agent-activity", "file": "WO-widget-out-agent-activity.md", "title": "agent-activity — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: open-event: click a feed row -> deep-link to that WO on the board (route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-agent-activity.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"agent-activity\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: route-out: /my/pulse.html?open=workdesk&wo= DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (route-out: /my/pulse.html?open=workdesk&wo=). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-agent-activity.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — none — pure client route-out). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-booking", "file": "WO-widget-out-booking.md", "title": "booking — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: confirm + cancel a booking (and add-to-calendar route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-booking.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"booking\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/booking (action=confirm|cancel) DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/booking (action=confirm|cancel)). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-booking.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — booking fn (verify write actions exist)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-files", "file": "WO-widget-out-files.md", "title": "files — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: send-file (drop a file to a machine) + open-file (route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-files.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"files\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/file-transfer + open link DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/file-transfer + open link). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-files.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — file-transfer fn (verify exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-orders", "file": "WO-widget-out-orders.md", "title": "orders — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: mark-fulfilled + open-order (route-out to the order detail). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-orders.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"orders\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: POST /.netlify/functions/orders (action=fulfill) DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (POST /.netlify/functions/orders (action=fulfill)). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-orders.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — orders fn (verify write action exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-widget-out-revenue", "file": "WO-widget-out-revenue.md", "title": "revenue — add the missing act-out ability (READ-ONLY -> LIVE-IO)", "what": "The widget's read abilities work (it shows live data). MISSING: open-wallet-actions: route-out to cash-out/transfer (a readout earns ability-first via route-out). Add it so the operator can ACT from the widget, not just look at it.", "why": "", "where": "components/widgets/widget-revenue.js (the widget — add the button + handler) · DNA/BLUEPRINT/INTERFACES/WIDGET_COMMANDS.json (DECLARE the new command under \"revenue\") · my/pulse.html (only if a new visible control is needed — widget or mode, NEVER a new page) · endpoint: route-out: open wallet action surface DO: 1. Read the widget .js + its WIDGET_COMMANDS.json entry (do not guess the shape). 2. Add the act-out control + handler to the widget (route-out: open wallet action surface). 3. Declare the new command in WIDGET_COMMANDS.json (id/does/invoke/args/example) — same shape as the existing read commands on this widget. 4. node --check the .js; verify the click writes/routes (browser or curl the endpoint). RAILS: Touch ONLY widget-revenue.js + this widget's WIDGET_COMMANDS.json entry (+ pulse.html if a control is truly needed). ONE chrome = cr-frame.js (never hand-paste old chrome). Widget or mode, never a new page. Do not touch any other widget. If the endpoint doesn't exist yet, STOP and note it (a missing backend fn is a separate card, not a silent stub).", "who": "", "status": "blocked", "claimer": "", "lane_raw": "MACHINE", "next": "whether the OUT endpoint already exists (verify first — wallet action surface (verify target exists)). If it must be built, that backend fn is a SEPARATE card; this card is the widget-side wire once the endpoint is live. [NORMALIZER 2026-08-07] R1: no STATUS field found — stamped open (was invisible to every organ)", "routed": "CHEAP-CLOUD-AGENT", "project": "widget ability-first sweep (S414 census)", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-xp-floors-and-rooms", "file": "WO-xp-floors-and-rooms.md", "title": "WO-xp-floors-and-rooms — Top contributors rise to higher FLOORS; keep building new ROOMS", "what": "WO-xp-floors-and-rooms — Top contributors rise to higher FLOORS; keep building new ROOMS", "why": "The building is the metaphor and the mechanic: as a contributor's XP rises they move UP to higher floors (access_level 2→3→4→5), and each floor has rooms only that floor can enter. Top contributors rise; the higher they go, the more they can do. And we must KEEP MAKING NEW ROOMS — the moment the top floor is 'done', the climb stops. New rooms above = the reason to keep rising. This is the ladder (DNA/DEV_FUNNEL_WALKTHROUGH.md) made spatial + never-finished. DO: 1. Define what each floor (access_level 2/3/4/5) unlocks — the rooms: e.g. F2 Widget Factory publish, F3 multiplayer cockpit seats, F4 dispatch/scope WOs, F5 resell-an-ARAYA-OS. (This defines the currently-blank L2-L4 zone.) 2. Wire the promotion: when profiles.xp crosses a floor threshold, raise profiles.access_level (server-side, via the xp-award path — depends on WO-xp-consolidation). 3. Make arriving on a new floor VISIBLE + rewarding — 'You reached Floor 3. The Squad Room is open.' Show the floor above so the next climb is always in view. 4. DOCTRINE: always keep at least one room above the current top floor under construction, so the ceiling keeps moving. Track it (an OPEN 'next room' card at all times).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "PUBLIC", "next": "", "routed": "CHEAP-CLOUD-AGENT", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false } ], "UNROUTED": [ { "id": "WO-S439-devsuite-wireup-batch", "file": "WO-S439-devsuite-wireup-batch.md", "title": "WO BATCH — Dev-Suite Wire-Up + 4-Week Plan (S439, 2026-08-14)", "what": "three inconsistent claim gates coexist (tasks-api=sign-in→+CLA; todo-claims-api=L5+ role; claim-wo=stub). Consolidate to ONE claim contract. WHERE: the 3 functions. DONE: one documented claim gate.", "why": "recurring leak; SENS wall is a net, not a fix. WHERE: the dev-news.json generator (not in obvious *.py/*.mjs — trace the Commander's-Log feed writer). DONE: generated dev-news.json never contains case numbers.", "where": "netlify/functions/claim-wo.mjs. DONE: no path lies about success.", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-S466-interface-dna-followups", "file": "WO-S466-interface-dna-followups.md", "title": "WO BATCH — S466 Interface-DNA Tracing + Vault Follow-ups (2026-08-28)", "what": "Show a doc's version chain using the `metadata.revision_of` links already written by save-v2. A \"versions\" affordance on a doc that has revisions.", "why": "save-v2 records the chain but nothing displays it yet.", "where": "`commander-vault-feed.mjs` (a revisions query) · widget-canvas doc view.", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-agent-readable-contract-floor", "file": "WO-agent-readable-contract-floor.md", "title": "WO-agent-readable-contract-floor — a widget claiming agent.readable=true must return live capabilities", "what": "WO-agent-readable-contract-floor — a widget claiming agent.readable=true must return live capabilities", "why": "Wave-3 batch-3 critic — NEW root: declared-vs-executable AGENT-READABILITY gap. Multiple widgets advertise agent.readable=true + voiceIds/aliases, but runtime introspection returns dead/capability-less data OR the execution path can't fulfill the claim (woboard declares agent-readability but returns a phantom claim-wo; page is fully driveable but ABSENT from WIDGET_COMMANDS.json so agents under-report it). This is distinct from WO-widget-contract-fleet-sweep (missing methods) — here the METHOD exists but LIES. DIRECTLY blocks the ARAYA curriculum (project_araya-curriculum): if a widget claims agent-readable but returns nothing, ARAYA's map teaches a capability that doesn't execute. DO: define the floor — a widget declaring agent.readable=true must (1) appear in WIDGET_COMMANDS.json, (2) return live, executable capability data on introspection (not a stub), (3) have its declared commands actually reachable via araya-chat [WIDGET:id]/command path. Sweep; make each claim true or drop the claim.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-ar-receipt-floor", "file": "WO-ar-receipt-floor.md", "title": "WO-ar-receipt-floor — every widget server-mutation must emit a visible receipt (nothing fails silently)", "what": "WO-ar-receipt-floor — every widget server-mutation must emit a visible receipt (nothing fails silently)", "why": "Wave-3 batch-2 completeness critic found a NEW uncarded cross-widget root: Action→Reaction NO-RECEIPT silent mutation. Server writes and money actions fire with no user-visible reaction/receipt across ≥3 widgets (comms markContacted/reopen, earn mission completions, calls save). This is the \"nothing fails silently\" doctrine violated at cluster scale — distinct from the telemetry clobber (that's the gauge; this is the user seeing nothing when they act). Batch-1's calls silent-death was the first instance; the critic confirms it's a pattern. DO: define the AR-receipt floor for a widget mutation (optimistic UI + confirmed/failed toast tied to the RESPONSE BODY, not just HTTP status — see the calls fix PR #1217 pattern). Sweep each widget's mutations; every one emits a visible confirm on success and a loud visible error on failure. Consider a shared helper.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-action-record-widget", "file": "WO-araya-action-record-widget.md", "title": "WO — Action Record widget: a visible receipt for every action ARAYA claims to take", "what": "WO — Action Record widget: a visible receipt for every action ARAYA claims to take", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-bug-system-cleanup", "file": "WO-araya-bug-system-cleanup.md", "title": "WO-araya-bug-system-cleanup — Fix stale bug-repo pointer + tighten ARAYA intake gate", "what": "WO-araya-bug-system-cleanup — Fix stale bug-repo pointer + tighten ARAYA intake gate", "why": "S446 traced ARAYA's ElevenLabs/voice bugs — they land in Supabase `araya_bugs` (128 rows, live) + GitHub `overkor-tek/consciousness-bugs`, NOT the chat's bugReport table. The repo MOVED (S411) but CLAUDE.md standing orders still say `overkillkulture/consciousness-bugs` → looking there shows nothing (\"where are ARAYA's bugs?\"). Also the intake gate `isNotABug()` blocks leaked prompts but low-signal fragments still slip through (#123 \"Yeah, go ahead and do that\", #119 \"Not working\"). DO: 1. Grep CLAUDE.md + .consciousness + scripts for `overkillkulture/consciousness-bugs`; repoint to `overkor-tek/consciousness-bugs`. 2. In `100X_DEPLOYMENT/netlify/functions/araya-tool-bugs.mjs` isNotABug(): reject bare acknowledgements / too-few-content-words / no problem-signal (add a min \"signal words\" heuristic beyond the current length check). 3. Optional: a weekly ARAYA-bug triage (dedupe, close low-signal) — its own loop.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-canned-reply-regression", "file": "WO-araya-canned-reply-regression.md", "title": "WO — Stop ARAYA's ability router from eating ordinary questions into canned \"Commander will see it\" acks", "what": "WO — Stop ARAYA's ability router from eating ordinary questions into canned \"Commander will see it\" acks", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-case-tool-live-hearings", "file": "WO-araya-case-tool-live-hearings.md", "title": "WO — ARAYA case tool returns stale hardcoded hearings → point it at a live source", "what": "WO — ARAYA case tool returns stale hardcoded hearings → point it at a live source", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-clip-shorts-extractor", "file": "WO-araya-clip-shorts-extractor.md", "title": "WO-araya-clip-shorts-extractor — Long-form video → AI-cut 9:16 shorts + captions + music", "what": "WO-araya-clip-shorts-extractor — Long-form video → AI-cut 9:16 shorts + captions + music", "why": "Johnny (S441 debrief) + the podcast plan both need it — drop a long-form video in, get postable shorts out. Reuses the transcription ability (WO-araya-transcribe-ability) for the transcript that drives clip selection. This is the media-production agent he asked for. DO: - Input: a long-form video (or one already transcribed). Use the transcript + simple heuristics (or an LLM pass) to pick 3-8 highlight moments. - Cut 9:16 vertical clips with ffmpeg; burn captions from the transcript; optional auto-music bed (reuse the music-gen pipeline). - Output to the user's Vault, review-then-post; hook the existing social fan-out for one-button posting. - No silent caps: show how many clips, let the user pick/trim.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-command-vs-conversation-intent", "file": "WO-araya-command-vs-conversation-intent.md", "title": "WO-araya-command-vs-conversation-intent: know when to ACT vs when to just TALK ABOUT it", "what": "WO-araya-command-vs-conversation-intent: know when to ACT vs when to just TALK ABOUT it", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-curriculum-from-registry", "file": "WO-araya-curriculum-from-registry.md", "title": "WO-araya-curriculum-from-registry — teach ARAYA everything from ONE generated map (no parallel doc)", "what": "WO-araya-curriculum-from-registry — teach ARAYA everything from ONE generated map (no parallel doc)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-araya-email-takeover", "file": "WO-araya-email-takeover.md", "title": "WO — ARAYA email takeover: email-to-vault door → filters/forwarding → the share-sheet door", "what": "WO — ARAYA email takeover: email-to-vault door → filters/forwarding → the share-sheet door", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-energy-createaccount-id-fracture", "file": "WO-araya-energy-createaccount-id-fracture.md", "title": "WO-araya-energy-createaccount-id-fracture — createAccount mints a random id, not the caller's canonical id", "what": "WO-araya-energy-createaccount-id-fracture — createAccount mints a random id, not the caller's canonical id", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-fake-action-confirmation", "file": "WO-araya-fake-action-confirmation.md", "title": "WO — ARAYA claims \"bug report filed\" without gathering the bug, and confirms success even when the write failed", "what": "WO — ARAYA claims \"bug report filed\" without gathering the bug, and confirms success even when the write failed", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-file-lifecycle-template", "file": "WO-araya-file-lifecycle-template.md", "title": "WO — ARAYA FILE LIFECYCLE = THE ABILITY TEMPLATE (give · share · retrieve)", "what": "WO — ARAYA FILE LIFECYCLE = THE ABILITY TEMPLATE (give · share · retrieve)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-file-open-ability", "file": "WO-araya-file-open-ability.md", "title": "WO — ARAYA ability #1: pull up a file, SHOW it, put it back", "what": "WO — ARAYA ability #1: pull up a file, SHOW it, put it back", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-infographics-agent", "file": "WO-araya-infographics-agent.md", "title": "WO-araya-infographics-agent — On-demand educational infographic cards", "what": "WO-araya-infographics-agent — On-demand educational infographic cards", "why": "Johnny (S441 debrief) makes many educational infographic cards for Facebook by hand — \"an easier way for people to learn.\" Automate: topic/points in → a clean branded image card out. DO: - Input: a topic + a few bullet points (or a paragraph the agent summarizes into points). - Render a branded card (reuse the brand-kit / dataviz standard) — title, 3-7 points, clean layout, light + dark. Export PNG to the user's Vault. - Optional: batch a series from a longer doc; route to social fan-out.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-araya-lever-not-autotrigger", "file": "WO-araya-lever-not-autotrigger.md", "title": "ARAYA DECIDES to open a widget (tool-use) — kill the keyword auto-override STATUS: open LANE: NEXT-BIG", "what": "ARAYA DECIDES to open a widget (tool-use) — kill the keyword auto-override STATUS: open LANE: NEXT-BIG", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT-BIG", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-memory-empty-read-anomaly", "file": "WO-araya-memory-empty-read-anomaly.md", "title": "WO-araya-memory-empty-read-anomaly — deployed araya-memory get_context returns empty for real account rows", "what": "WO-araya-memory-empty-read-anomaly — deployed araya-memory get_context returns empty for real account rows", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-memory-read-auth", "file": "WO-araya-memory-read-auth.md", "title": "WO-araya-memory-read-auth — gate unauthenticated READS of araya-memory", "what": "WO-araya-memory-read-auth — gate unauthenticated READS of araya-memory", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-offline-mode", "file": "WO-araya-offline-mode.md", "title": "WO-araya-offline-mode — ARAYA runs with no internet", "what": "WO-araya-offline-mode — ARAYA runs with no internet", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-own-voice-downloadable", "file": "WO-araya-own-voice-downloadable.md", "title": "WO-araya-own-voice-downloadable — ARAYA carries HER OWN neural voice everywhere (kill the stock device fallback)", "what": "WO-araya-own-voice-downloadable — ARAYA carries HER OWN neural voice everywhere (kill the stock device fallback)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-per-user-scoped-token", "file": "WO-araya-per-user-scoped-token.md", "title": "WO-araya-per-user-scoped-token — Per-user scoped API tokens (builders reach ONLY their own data)", "what": "WO-araya-per-user-scoped-token — Per-user scoped API tokens (builders reach ONLY their own data)", "why": "To let Johnny / Odin / any builder use ARAYA (web OR their own Claude Code MCP) WITHOUT the admin key (CR_83d0…, full access to EVERYONE). S441: wiring Johnny's Claude Code was BLOCKED because the only credential is that admin key — handing a new person full-system access breaks no-single-capture. Per-user scoped tokens = the safe unlock for the whole builder-cockpit vision. DO: - Mint per-user tokens (tied to profile/user_id) scoping list/create/update/delete to rows where assignee/owner == that user (+ their allowed avenues/scope). - MCP server accepts `ARAYA_USER_KEY` (not admin); enforce scope SERVER-SIDE (never trust client). - Revocable, logged, no PII in the token. - Deliver Johnny a scoped token + the MCP snippet so \"show my tasks\" works on his box safely.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-presenter-artifact-pane", "file": "WO-araya-presenter-artifact-pane.md", "title": "WO — ARAYA Presenter: the artifact pane (Claude & ARAYA \"show their work\")", "what": "WO — ARAYA Presenter: the artifact pane (Claude & ARAYA \"show their work\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-product-dna", "file": "WO-araya-product-dna.md", "title": "WO-araya-product-dna — Product DNA record: ARAYA L1 (the template for every product; unlocks L2/L3)", "what": "Every product we SELL gets ONE complete \"Product DNA\" record — the single place holding everything a buyer AND a builder needs. Define the repeatable 6-part shape, fill it for **ARAYA L1** (the thing we're selling right now), and stub **L2 / L3** so the ladder is definable. Includes the on-page ARAYA UX redesign (research how others embed/lease AI; replace the big-A intercom orb with something simpler that works on mobile).", "why": "We're selling an object; the object needs a blueprint. Today it's scattered — listing in products.json, wiring in MECHANICS_LOG_VOICE, abilities in COMPONENT_REGISTRY, and NO customer explanation / onboarding / L2 / L3. One Product DNA record per product = (a) the buyer-trust asset, (b) the clone template for the platform, (c) the thing that makes L2/L3 definable (same DNA + more abilities).", "where": "EXTEND existing homes (no new store, no-8th-copy): `DNA/MECHANICS_LOG_VOICE.md` (wiring) · `store/products.json` (listing) · `DNA/COMPONENT_REGISTRY.json` → `intercom-orb` (UX object) · a per-product DNA record that INDEXES these + adds the missing customer-explanation + onboarding.", "who": "araya lane.", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-signout-loop-forge-passport", "file": "WO-araya-signout-loop-forge-passport.md", "title": "WO-araya-signout-loop-forge-passport: sign-out immediately auto-signs back in (can't switch accounts)", "what": "WO-araya-signout-loop-forge-passport: sign-out immediately auto-signs back in (can't switch accounts)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-transcribe-ability", "file": "WO-araya-transcribe-ability.md", "title": "WO-araya-transcribe-ability — ARAYAOS \"Transcribe\" ability: add-from-store widget that turns any audio/video into text", "what": "WO-araya-transcribe-ability — ARAYAOS \"Transcribe\" ability: add-from-store widget that turns any audio/video into text", "why": "Commander's ask, S441 — \"this would be a great ability for ARAYAOS: go to the store, see a transcribing app, add it to your main widget list, and it transcribes a video or audio recording (mp4/m4a/mp3/wav).\" This is the intake on-ramp for the whole WO Router: a recording → text → tasks/ vault. FEASIBILITY PROVEN THIS SESSION (S441): a 26MB / ~13-min `.m4a` was transcribed on CP3 with local `faster-whisper` (small.en) after an `ffmpeg` convert to 16kHz mono wav; and CP2's GPU Whisper endpoint is live (`http://100.119.89.85:8880/stt`, cuda). So the backend is not a research question — it's a wiring job. DO: - STORE LISTING: add \"Transcribe\" to the ARAYAOS store/marketplace with a real screenshot + one-line description (\"Drop in any audio or video — get the text back, attached to your Vault/Notes\"). - ADD-TO-WIDGETS: reuse the existing add-a-widget / pack-bind flow so it lands in the user's main widget list (owner-scoped; no PII). Collapses when not in use like other widgets. - THE WIDGET: accepts a file (m4a/mp3/mp4/mov/wav) OR a recording already in the Vault. On submit: ffmpeg → 16kHz mono wav → transcribe. Show a visible \"transcribing…\" state (the she's-thinking rule). - BACKEND (pick + wire, don't rebuild): primary = CP2 GPU Whisper `POST :8880/stt` (fast); fallback = local `faster-whisper` (small.en, int8) for offline. Same code path as the S441 proof script (`Downloads/transcribe_voice.py`) — promote that into a real endpoint. - OUTPUT: write the transcript to the user's Vault/Notes (reuse the notes-feed backend), tagged `transcript`, with a \"→ turn into tasks\" button that tees up WO rows (feeds the WO Router). - LIMITS: show duration/size cap + cost note; long files run async with a \"ready\" ping (no silent cap).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-button-and-widget-puppet-strings", "file": "WO-araya-voice-button-and-widget-puppet-strings.md", "title": "WO — ARAYA voice button on the dashboard + voice-controls-the-widgets (\"puppet strings\")", "what": "WO — ARAYA voice button on the dashboard + voice-controls-the-widgets (\"puppet strings\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-compat-red-tape", "file": "WO-araya-voice-compat-red-tape.md", "title": "WO-araya-voice-compat-red-tape: unwrap the voice-length limiting + the failing auto widget-TTS layer", "what": "WO-araya-voice-compat-red-tape: unwrap the voice-length limiting + the failing auto widget-TTS layer", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-notification-arbitration", "file": "WO-araya-voice-notification-arbitration.md", "title": "WO — One audio arbiter: ARAYA never talks over notifications (turn-taking)", "what": "WO — One audio arbiter: ARAYA never talks over notifications (turn-taking)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-araya-voice-streaming-tts", "file": "WO-araya-voice-streaming-tts.md", "title": "WO — Stream ARAYA's answer + TTS per-sentence (first audio in ~1-2s, not ~11s)", "what": "WO — Stream ARAYA's answer + TTS per-sentence (first audio in ~1-2s, not ~11s)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-aries-dissect", "file": "WO-aries-dissect.md", "title": "dissect Johnny's \"IRON ARIES\" software (ARIES_CORE v0.1) STATUS: open LANE: NEXT", "what": "dissect Johnny's \"IRON ARIES\" software (ARIES_CORE v0.1) STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-attach-share-vault-roundtrip", "file": "WO-attach-share-vault-roundtrip.md", "title": "WO-attach-share-vault-roundtrip — Make the attach→vault loop actually close (the \"does it work\" bug)", "what": "WO-attach-share-vault-roundtrip — Make the attach→vault loop actually close (the \"does it work\" bug)", "why": "The ability bar's ＋ATTACH and vault read from DIFFERENT stores, so nothing attached ever appears in the vault: - ATTACH (araya-file-upload.mjs ~line 291) writes table `araya_documents` + storage bucket `araya-documents`. - VAULT (vault-api.mjs line 131-132) reads table `vault_items` + storage bucket `vault`. Two tables, two buckets, never bridged. Commander S425: \"we've never once shared stuff to a vault, pulled it back up, looked at it, put it back.\" ENABLES: closes step 3 (VAULT) of WO-one-foundational-page-that-works; unblocks the foundational window; proves the attach/share/vault loop for every dash (the ability bar is inherited by all). DO: Pick ONE bridge and make the loop close (prefer the smallest that works, then note the unify path): 1. FASTEST: on attach, ALSO insert a `vault_items` row (and upload to the `vault` bucket) so the attached file shows in the vault immediately — OR 2. have vault-api's list (vault-api.mjs ~line 131) read a UNION of `vault_items` + `araya_documents` scoped to the caller — OR 3. UNIFY onto one table + one bucket (the real fix; bigger). State which you chose and why. Also wire ⤴SHARE (the \"out\" side) to push a vault item to a room/user (or at minimum a working share link) — today it's unproven. Keep user-scoping intact: vault-api scopes every read to the caller's verified identifiers (vault-api.mjs line 40, 131) — the attached rows MUST carry the same user_id/scope so a user can never see another user's files.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-auth-getuuid-door", "file": "WO-auth-getuuid-door.md", "title": "WO-auth-getuuid-door — Auth.getUUID(): the ONE identity door (sturdy-state stitch 2)", "what": "WO-auth-getuuid-door — Auth.getUUID(): the ONE identity door (sturdy-state stitch 2)", "why": "", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-board-bounty-field", "file": "WO-board-bounty-field.md", "title": "WO-board-bounty-field — put a $ bounty on board cards (the hiring plug)", "what": "WO-board-bounty-field — put a $ bounty on board cards (the hiring plug)", "why": "With $1M and hiring, the board becomes a marketplace: a card with a $ value = a paid task any human/contractor/agent can claim from the SAME queue CP2 just joined. Card already has `xp`; add money. DO: Add `bounty_usd` column to dev_board_tasks (migration, additive). Map xp->$ (interim: xp IS the bounty unit until $ set). Surface bounty on board-feed + the card UI. cloud_queue/claim already works — a paid claim is the same claim with a payout on complete+approve. Gate payout behind review (preview-only).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-build-vs-buy-chat-store", "file": "WO-build-vs-buy-chat-store.md", "title": "WO — Build-vs-buy verdict: Main Chat vs Discord · The Store vs Shopify (parity grade + forecast + cutoff)", "what": "WO — Build-vs-buy verdict: Main Chat vs Discord · The Store vs Shopify (parity grade + forecast + cutoff)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-buildguild-auth-gate-check", "file": "WO-buildguild-auth-gate-check.md", "title": "WO-buildguild-auth-gate-check — Fix the Build Guild login gate (GitHub · Google · magic link)", "what": "WO-buildguild-auth-gate-check — Fix the Build Guild login gate (GitHub · Google · magic link)", "why": "⚠️ Commander flagged VERY IMPORTANT (S441) — the gate to Build Guild is \"not good\"; the three login providers need checking. This is the FRONT DOOR: if people can't get in, nothing downstream matters (cockpits, tasks, onboarding all sit behind it). Pairs with the Supabase auth config fix already in FORWARD_PLAN Lane 1 (persistSession + autoRefreshToken + signOut scope:local — the \"loses users / can't log back in\" fix). DO: - Live-test each provider end-to-end on the Build Guild login: **GitHub OAuth · Google OAuth · magic-link email** — each must land the user IN with a WORKING, PERSISTED session (not a bounce, not a lost session). - Check the provider consoles against `DNA/MECHANICS_LOG_IDENTITY.md` gate map + provider registry: redirect URIs, client IDs/secrets, allowed domains, the magic-link email template + sender. - Record each console in `provider_passports` (DNA/PROVIDERS/_PASSPORT_FORM.md). - Fix what's broken. NEVER rotate a user password without notify + a working recovery door (magic link is the always-works door).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-calls-widget-real-buttons", "file": "WO-calls-widget-real-buttons.md", "title": "WO — Calls widget: make the \"Call back\" buttons real", "what": "WO — Calls widget: make the \"Call back\" buttons real", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-chat-canonical-toolbar", "file": "WO-chat-canonical-toolbar.md", "title": "WO-chat-canonical-toolbar — Bring the ONE HUD dock to Main Chat", "what": "WO-chat-canonical-toolbar — Bring the ONE HUD dock to Main Chat", "why": "Commander flagged it TWICE (\"need normal toolbar… offbrand\"). The pink bug button was recolored (S446) but the nav is still Munia's own MenuBar, not the canonical CR dock (cr-frame.js / HUD_MERGE_BLUEPRINT). Doctrine: ONE HUD everywhere, never a second bar. This is the last OPEN chat chrome item. DECISION (Commander, S447): **PORT cr-frame.js into a real React dock component** (canonical ONE-HUD source, reusable as a shared package — NOT a MenuBar restyle/look-alike). Retire Munia's MenuBar carefully. Build unblocked. DO: 1. ✅ DECISION MADE (above): port the full cr-frame.js A-dock into React. Don't restyle MenuBar. 2. Read `100X_DEPLOYMENT/DNA/HUD_MERGE_BLUEPRINT.md` + `components/cr-frame.js` (vanilla JS A-dock) + memory feedback_toolbars-on-everywhere / feedback_hud-ux-doctrines. 3. Port the 5-door bottom dock into a React component (thumb-zone, identical every page); wire ARAYA door → in-chat ARAYA DM (already live), GO → search, DRAWER → app-drawer sheet. 4. Retire Munia's MenuBar bottom bar (mobile) + reconcile the desktop sidebar — no second bar (HUD_MERGE law). 5. Keep the emerald bug button OR fold it into the dock per the no-floating doctrine.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-chat-streaming-typed", "file": "WO-chat-streaming-typed.md", "title": "WO — Stream ARAYA's typed-chat replies (kill the dead-air stare)", "what": "WO — Stream ARAYA's typed-chat replies (kill the dead-air stare)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-cockpit-shell", "file": "WO-cockpit-shell.md", "title": "WO — Cockpit shell: import · view · add-ability · save (Johnny / Odin / Commander)", "what": "WO — Cockpit shell: import · view · add-ability · save (Johnny / Odin / Commander)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-commander-weak-widgets", "file": "WO-commander-weak-widgets.md", "title": "WO — Commander's 3 weak widgets: agent-activity, keys, files-empty-state", "what": "WO — Commander's 3 weak widgets: agent-activity, keys, files-empty-state", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-contacts-comms-spine", "file": "WO-contacts-comms-spine.md", "title": "foundational contacts + consent model — the spine a whole Communications app could grow from", "what": "Design (decision doc first, then build) a foundational contacts + visibility + consent system — who can see whose contacts, who can be found via a searchable directory, and who can message whom. Model the actual message/DM mechanics on the EXISTING, already-canonical DM flow (components/widget-dm.js + netlify/functions/dm-api.mjs — verdict: [[project_builder-revolution-build-guild]] BG-5, \"System A is CANONICAL\"), and copy proven visibility/consent PATTERNS from other platforms rather than inventing new ones: - Phone contacts: your list is LOCAL/private by default; nobody is auto-added to anyone else's. - Discord: DMs open automatically between mutual friends or shared-server members; a friend REQUEST is required outside that (mutual accept, not one-sided visibility). - Instagram/Meta: public vs private account toggle; non-mutual senders land in a separate \"message requests\" folder instead of the main inbox (consent-gated, not blocked outright). - LinkedIn: an explicit \"who can see my connections\" privacy setting, separate from having a connection at all. Core pieces to land: 1. Personal contacts are PRIVATE-BY-DEFAULT, owned per-user — populating your own contacts never leaks them into anyone else's view. 2. A searchable/discoverable directory is a SEPARATE, OPT-IN surface — a person chooses IF and HOW they're listed (public / room-only / invite-only / not listed). Default = NOT LISTED. 3. Messaging permission (\"can A message B\") extends the existing L0-L7 permission ladder ([[project_permission-ladder]]) with a consent edge: shared room/mission membership, mutual opt-in, or an explicit invite — never just \"both accounts exist in the system.\" 4. A message-request-style holding lane for the non-mutual case (Instagram pattern) instead of either a hard block or open inbox.", "why": "Commander (S432, 2026-08-11): \"we're gonna have to figure out our foundational contact system and who's allowed to view whose contacts... some sort of orchestrator on who talks to who because now we've got three different groups... people start populating their own contacts, we can't get them into everybody else's contacts... we also have to ask people who they want their contact listed to, if anyone.\" Trigger: the BG-5 identity bridge just shipped this session ([[project_builder-revolution-build-guild]]), meaning two previously-separate user pools (the main site's Supabase-auth users and Builder Revolution's Prisma-auth users) now share ONE identity, plus a third population (legal/case clients on the Guardian/Case Builder side) already lives in the same system. Verified live: `netlify/functions/contacts-api.mjs` has ZERO visibility/opt-in fields today — no privacy model exists at all, so nothing currently stops one population's contacts from being visible to another. Commander's own framing: \"this could turn into a whole communications app if we figure out a few things these other platforms are missing and add them\" — real ambition, but the instruction is explicit: copy what other platforms already solved, don't reinvent the wheel.", "where": "netlify/functions/contacts-api.mjs (add visibility/opt-in fields + consent-gated reads) · components/widget-contacts.wdo.js (client UI) · components/widget-dm.js + netlify/functions/dm-api.mjs (the reference message/consent flow to extend, not replace) · the identity layer the BG-5 bridge uses (Supabase Auth as sole issuer, verified JWT — see overkillkulture/builder-revolution PR #3, `supabase-bridge` NextAuth provider) · [[project_permission-ladder]] (L0-L7) for the consent-edge extension.", "who": "Claude direct for the decision doc + schema; human-or-ai for the \"audit other platforms\" research slice (browser-only friendly)", "status": "open", "claimer": "", "lane_raw": "INSIDE", "next": "", "routed": "UNROUTED", "project": "Communications", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-cross-ai-bootstrap-relay", "file": "WO-cross-ai-bootstrap-relay.md", "title": "Copy your work out of ANY AI → machine turns it into a leveled bootstrap WO with an 8-facet index name → paste into the next AI and it takes off STATUS: blocked LANE: NEXT", "what": "Copy your work out of ANY AI → machine turns it into a leveled bootstrap WO with an 8-facet index name → paste into the next AI and it takes off STATUS: blocked LANE: NEXT", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "outside-ok", "cloud_ready": false }, { "id": "WO-default-for-tier-packs", "file": "WO-default-for-tier-packs.md", "title": "WO — default_for_tier: buying L1/L2/L3 auto-binds the tier pack as your rail", "what": "WO — default_for_tier: buying L1/L2/L3 auto-binds the tier pack as your rail", "why": "", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-dual-mode-personal-public-line", "file": "WO-dual-mode-personal-public-line.md", "title": "ONE number that knows the owner (personal assistant) vs the public (receptionist) STATUS: open LANE: NEXT-BIG", "what": "ONE number that knows the owner (personal assistant) vs the public (receptionist) STATUS: open LANE: NEXT-BIG", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT-BIG", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-entity-trust-professional", "file": "WO-entity-trust-professional.md", "title": "WO-entity-trust-professional — Entity/trust bones — book a licensed pro to ratify the holding structure", "what": "WO-entity-trust-professional — Entity/trust bones — book a licensed pro to ratify the holding structure", "why": "Section 4: everything is implicitly Commander-personal plus one LLC. Trust/holdco layer needs a licensed professional; standard boring structures only. DO: Commander: pick a business attorney or CPA (Idaho or WA), one consult on: trust to holdco to opco shape, which entity owns ARAYA/brands/courses, where each revenue stream lands. Bring THE_ORG_BONES.md section 4 as the agenda.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-export-components-arm-araya-os", "file": "WO-export-components-arm-araya-os.md", "title": "WO-export-components-arm-araya-os — export every system/component as its own object → widget → ARAYA OS capability", "what": "WO-export-components-arm-araya-os — export every system/component as its own object → widget → ARAYA OS capability", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-external-dev-mvp-drop-anywhere", "file": "WO-external-dev-mvp-drop-anywhere.md", "title": "WO — Vault \"drop-anywhere\" overlay (GOOD FIRST PR / external-dev MVP)", "what": "WO — Vault \"drop-anywhere\" overlay (GOOD FIRST PR / external-dev MVP)", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-file-indexer-videographer-naming", "file": "WO-file-indexer-videographer-naming.md", "title": "WO — The file-indexer machine: \"index files to divinity\" with videographer-grade names + tags", "what": "WO — The file-indexer machine: \"index files to divinity\" with videographer-grade names + tags", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-files-widget-vault-store-unify", "file": "WO-files-widget-vault-store-unify.md", "title": "WO-files-widget-vault-store-unify — the \"Files\" widget shows a DIFFERENT store than the vault ARAYA speaks", "what": "WO-files-widget-vault-store-unify — the \"Files\" widget shows a DIFFERENT store than the vault ARAYA speaks", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-house--claude-ledger", "file": "WO-fill-organ-house--claude-ledger.md", "title": "WO-fill-organ-house--claude-ledger — Fill LEDGER organ for HOUSE .claude", "what": "WO-fill-organ-house--claude-ledger — Fill LEDGER organ for HOUSE .claude", "why": "HOUSE node '.claude' is missing LEDGER organ (completeness: 80.0%) DO: Implement LEDGER for HOUSE/.claude: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-house--consciousness-gauge", "file": "WO-fill-organ-house--consciousness-gauge.md", "title": "WO-fill-organ-house--consciousness-gauge — Fill GAUGE organ for HOUSE .consciousness", "what": "WO-fill-organ-house--consciousness-gauge — Fill GAUGE organ for HOUSE .consciousness", "why": "HOUSE node '.consciousness' is missing GAUGE organ (completeness: 80.0%) DO: Implement GAUGE for HOUSE/.consciousness: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-11-0-board", "file": "WO-fill-organ-pcf-11-0-board.md", "title": "WO-fill-organ-pcf-11-0-board — Fill BOARD organ for PCF 11.0", "what": "WO-fill-organ-pcf-11-0-board — Fill BOARD organ for PCF 11.0", "why": "PCF node '11.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/11.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-11-0-heartbeat", "file": "WO-fill-organ-pcf-11-0-heartbeat.md", "title": "WO-fill-organ-pcf-11-0-heartbeat — Fill HEARTBEAT organ for PCF 11.0", "what": "WO-fill-organ-pcf-11-0-heartbeat — Fill HEARTBEAT organ for PCF 11.0", "why": "PCF node '11.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/11.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-12-0-board", "file": "WO-fill-organ-pcf-12-0-board.md", "title": "WO-fill-organ-pcf-12-0-board — Fill BOARD organ for PCF 12.0", "what": "WO-fill-organ-pcf-12-0-board — Fill BOARD organ for PCF 12.0", "why": "PCF node '12.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/12.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-12-0-heartbeat", "file": "WO-fill-organ-pcf-12-0-heartbeat.md", "title": "WO-fill-organ-pcf-12-0-heartbeat — Fill HEARTBEAT organ for PCF 12.0", "what": "WO-fill-organ-pcf-12-0-heartbeat — Fill HEARTBEAT organ for PCF 12.0", "why": "PCF node '12.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/12.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-13-0-board", "file": "WO-fill-organ-pcf-13-0-board.md", "title": "WO-fill-organ-pcf-13-0-board — Fill BOARD organ for PCF 13.0", "what": "WO-fill-organ-pcf-13-0-board — Fill BOARD organ for PCF 13.0", "why": "PCF node '13.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/13.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-13-0-heartbeat", "file": "WO-fill-organ-pcf-13-0-heartbeat.md", "title": "WO-fill-organ-pcf-13-0-heartbeat — Fill HEARTBEAT organ for PCF 13.0", "what": "WO-fill-organ-pcf-13-0-heartbeat — Fill HEARTBEAT organ for PCF 13.0", "why": "PCF node '13.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/13.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-3-0-board", "file": "WO-fill-organ-pcf-3-0-board.md", "title": "WO-fill-organ-pcf-3-0-board — Fill BOARD organ for PCF 3.0", "what": "WO-fill-organ-pcf-3-0-board — Fill BOARD organ for PCF 3.0", "why": "PCF node '3.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/3.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-3-0-heartbeat", "file": "WO-fill-organ-pcf-3-0-heartbeat.md", "title": "WO-fill-organ-pcf-3-0-heartbeat — Fill HEARTBEAT organ for PCF 3.0", "what": "WO-fill-organ-pcf-3-0-heartbeat — Fill HEARTBEAT organ for PCF 3.0", "why": "PCF node '3.0' is missing HEARTBEAT organ (completeness: 60.0%) DO: Implement HEARTBEAT for PCF/3.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-4-0-board", "file": "WO-fill-organ-pcf-4-0-board.md", "title": "WO-fill-organ-pcf-4-0-board — Fill BOARD organ for PCF 4.0", "what": "WO-fill-organ-pcf-4-0-board — Fill BOARD organ for PCF 4.0", "why": "PCF node '4.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/4.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-4-0-state", "file": "WO-fill-organ-pcf-4-0-state.md", "title": "WO-fill-organ-pcf-4-0-state — Fill STATE organ for PCF 4.0", "what": "WO-fill-organ-pcf-4-0-state — Fill STATE organ for PCF 4.0", "why": "PCF node '4.0' is missing STATE organ (completeness: 60.0%) DO: Implement STATE for PCF/4.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-5-0-board", "file": "WO-fill-organ-pcf-5-0-board.md", "title": "WO-fill-organ-pcf-5-0-board — Fill BOARD organ for PCF 5.0", "what": "WO-fill-organ-pcf-5-0-board — Fill BOARD organ for PCF 5.0", "why": "PCF node '5.0' is missing BOARD organ (completeness: 80.0%) DO: Implement BOARD for PCF/5.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-7-0-board", "file": "WO-fill-organ-pcf-7-0-board.md", "title": "WO-fill-organ-pcf-7-0-board — Fill BOARD organ for PCF 7.0", "what": "WO-fill-organ-pcf-7-0-board — Fill BOARD organ for PCF 7.0", "why": "PCF node '7.0' is missing BOARD organ (completeness: 60.0%) DO: Implement BOARD for PCF/7.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-7-0-state", "file": "WO-fill-organ-pcf-7-0-state.md", "title": "WO-fill-organ-pcf-7-0-state — Fill STATE organ for PCF 7.0", "what": "WO-fill-organ-pcf-7-0-state — Fill STATE organ for PCF 7.0", "why": "PCF node '7.0' is missing STATE organ (completeness: 60.0%) DO: Implement STATE for PCF/7.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fill-organ-pcf-9-0-board", "file": "WO-fill-organ-pcf-9-0-board.md", "title": "WO-fill-organ-pcf-9-0-board — Fill BOARD organ for PCF 9.0", "what": "WO-fill-organ-pcf-9-0-board — Fill BOARD organ for PCF 9.0", "why": "PCF node '9.0' is missing BOARD organ (completeness: 80.0%) DO: Implement BOARD for PCF/9.0: create the required files/receipts/registry entries", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-fundraising-business-plan-define", "file": "WO-fundraising-business-plan-define.md", "title": "WO-fundraising-business-plan-define — DEFINE: Fundraising & Business Plan", "what": "WO-fundraising-business-plan-define — DEFINE: Fundraising & Business Plan", "why": "North-Star chunk: Fundraising & Business Plan. Get everyone organized + running as a business; build the business plan + the path to raise money on tech. Make the reports paid users want to see before they invest. Paid users ar ENABLES: completing this turns 'Fundraising & Business Plan' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/fundraising-business-plan.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-funnel-template-standard", "file": "WO-funnel-template-standard.md", "title": "WO — The ONE Funnel/Page Template + GATE (the center point of reference)", "what": "WO — The ONE Funnel/Page Template + GATE (the center point of reference)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-gh-window-explosion", "file": "WO-gh-window-explosion.md", "title": "WO — Kill the gh.exe window explosion (~30 console windows flash ~hourly)", "what": "WO — Kill the gh.exe window explosion (~30 console windows flash ~hourly)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-green-projects-live-store", "file": "WO-green-projects-live-store.md", "title": "WO-green-projects-live-store — Supabase table + CRUD for green projects (IF surface revives)", "what": "WO-green-projects-live-store — Supabase table + CRUD for green projects (IF surface revives)", "why": "PR #1140 (S427, closed S453 by merge-captain triage) built the whole backend (S427_green_projects.sql migration + green-projects-api.mjs CRUD) but the demand side is dead — the widget is unmounted, and merging a live DB+API for a dead surface violates the no-orphan law. The code is good; the timing is wrong. SALVAGE: closed PR #1140 (branch opencode-905-green-project-storage preserved) — lift `S427_green_projects.sql` + `green-projects-api.mjs` nearly as-is when this unblocks.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-guardian-forge-opensource-tools", "file": "WO-guardian-forge-opensource-tools.md", "title": "WO-guardian-forge-opensource-tools — Package Guardian Forge's open-source tools to sell on ARAYA OS", "what": "WO-guardian-forge-opensource-tools — Package Guardian Forge's open-source tools to sell on ARAYA OS", "why": "Guardian Forge (Unite The Movement) is meant to be the place open-source tools live and spread — but tools that aren't packaged and priced don't fund the movement. Turning the Guardian Forge open-source toolset into clean, sellable listings on ARAYA OS gives the mission a revenue engine while keeping the tools open (sell the build/support/hosting, not the license). It pairs with the electrical-devices marketplace as the \"tools\" half of the sourcing story. DO: Catalog the Guardian Forge open-source tools, decide the open-source-friendly monetization (support / kits / hosting / done-for-you), and list them on ARAYA OS through the seller funnel. See RING 3.", "where": "Build INTO the ONE shell (Guardian Forge storefront section in pulse); reuse the seller funnel / Stripe — no second cart.", "who": "COMMANDER-authored; buyer-facing catalog public; contributor tools credited. Unclaimed. SPAWN: contributor-submission flow (let outside builders add tools to the Forge), affiliate/XP share-loop. RELATED: WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, project_unite-the-movement-blueprint, project_creator-tools-platform-vision, project_three-bucket-contributor-doctrine, project_508c1a-structure SOURCE: Commander dictation S426 — \"open source tools for guardian forge to sell on araya os.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-guardian-video-cta-landing", "file": "WO-guardian-video-cta-landing.md", "title": "WO — Guardian video-CTA landing (where warm traffic from the pro-se videos lands)", "what": "WO — Guardian video-CTA landing (where warm traffic from the pro-se videos lands)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-guild-door-roundtrip", "file": "WO-guild-door-roundtrip.md", "title": "WO — Build Guild door: arrive signed-in, always a way home", "what": "WO — Build Guild door: arrive signed-in, always a way home", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-health-detox-frequency-tek-marketplace", "file": "WO-health-detox-frequency-tek-marketplace.md", "title": "WO-health-detox-frequency-tek-marketplace — Curated health/detox/frequency tek storefront on ARAYA OS", "what": "WO-health-detox-frequency-tek-marketplace — Curated health/detox/frequency tek storefront on ARAYA OS", "why": "There's huge, scattered demand for health/detox/frequency tek — PEMF, structured water, parasite/detox cleanse, peptides, frequency/Rife-style devices — sold in a hundred sketchy corners with no trusted, curated one-spot. Aggregating reputable makers into a single ARAYA OS storefront gives buyers a vetted place and makers distribution + payout, feeding the same 20%-cut engine as the electrical + Guardian Forge marketplaces. COMPLIANCE IS PART OF THE JOB (see rails) — these categories carry real FDA/FTC claim risk. DO: Curate the categories, source + contact reputable makers, and stand up a compliant curated storefront that sells through the seller funnel — with a claims/compliance guard baked in from step one. See RING 3.", "where": "Build INTO the ONE shell (Health Tek storefront section in pulse); reuse the seller funnel / Stripe — no second cart.", "who": "COMMANDER-authored; buyer catalog public; maker outreach commander-only. Unclaimed. SPAWN: per-category deep-dive cards; a compliance/disclaimer-template card (reusable across all product marketplaces). RELATED: WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, WO-guardian-forge-opensource-tools, project_offerings-consolidation, project_creator-tools-platform-vision SOURCE: Commander dictation S426 — \"all health / detox / parasite cleanse tek, PEMF, structured water, peptide frequency, all that stuff.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-human-on-the-phone-per-product-define", "file": "WO-human-on-the-phone-per-product-define.md", "title": "WO-human-on-the-phone-per-product-define — DEFINE: Human on the Phone per Product", "what": "WO-human-on-the-phone-per-product-define — DEFINE: Human on the Phone per Product", "why": "North-Star chunk: Human on the Phone per Product. A real human prepared to answer the call for every product. Commander needs a good WIRED headset (Bluetooth is too dinky, dies). ENABLES: completing this turns 'Human on the Phone per Product' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/human-on-the-phone-per-product.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-identity-rekey-email-to-uuid", "file": "WO-identity-rekey-email-to-uuid.md", "title": "WO-identity-rekey-email-to-uuid — re-key the email-keyed backends onto the Supabase UUID", "what": "WO-identity-rekey-email-to-uuid — re-key the email-keyed backends onto the Supabase UUID", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-import-starting-point", "file": "WO-import-starting-point.md", "title": "WO — THE IMPORT STARTING POINT (the universal \"get your data in\" step)", "what": "WO — THE IMPORT STARTING POINT (the universal \"get your data in\" step)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-interface-progression-engine", "file": "WO-interface-progression-engine.md", "title": "WO — THE PROGRESSION ENGINE (the interface advances with the user)", "what": "WO — THE PROGRESSION ENGINE (the interface advances with the user)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-landing-page-one-mold", "file": "WO-landing-page-one-mold.md", "title": "make \"Welcome to the Revolution\" the ONE landing mold; clone it for Johnny/Rachel STATUS: open LANE: NEXT", "what": "make \"Welcome to the Revolution\" the ONE landing mold; clone it for Johnny/Rachel STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-leads-registry-conflict-commander-ops", "file": "WO-leads-registry-conflict-commander-ops.md", "title": "WO-leads-registry-conflict-commander-ops — leads slot routes to commander-ops, not widget-leads2 (de-dupe)", "what": "WO-leads-registry-conflict-commander-ops — leads slot routes to commander-ops, not widget-leads2 (de-dupe)", "why": "Wave-3 comb (S442) C2-split found on `leads`: 1. REGISTRY CONFLICT — DNA/WIDGET_REGISTRY.json id 'leads' says render:'url' → '/commander-ops.html#leads', widget:null. It does NOT know widget-leads2.js exists and routes the leads slot to commander-ops (which CANONICAL_REGISTRY says is NOT the dashboard). Two registries disagree on what 'leads' is. 2. LIVE DUPLICATE — commander-ops.html still carries its own hand-rolled leads panel (loadOpsLeads/markOpsLead hitting /.netlify/functions/araya-leads directly) — the exact fork my/index.html declared dead. Two live leads implementations. DO: - Point the leads registry row at widget-leads2.js (the shipped widget) instead of the commander-ops URL; verify the slot opens the widget on prod. - Decide commander-ops.html's leads panel: retire it (redirect to the widget) or explicitly mark it a separate ops view — but it must not be a second silent implementation of the same data. - Re-check the org chart for a leads name_collision cluster and clear it.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-main-chat-punchlist-s443", "file": "WO-main-chat-punchlist-s443.md", "title": "WO — MAIN CHAT PUNCH LIST (everything wrong, carded) · S443 · 2026-08-17", "what": "WO — MAIN CHAT PUNCH LIST (everything wrong, carded) · S443 · 2026-08-17", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-merge-captain-honor-block", "file": "WO-merge-captain-honor-block.md", "title": "WO-merge-captain-honor-block — Merge Captain must FAIL a PR that carries a standing content BLOCK", "what": "WO-merge-captain-honor-block — Merge Captain must FAIL a PR that carries a standing content BLOCK", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-mesh-comms-builders-as-nodes-define", "file": "WO-mesh-comms-builders-as-nodes-define.md", "title": "WO-mesh-comms-builders-as-nodes-define — DEFINE: Mesh Comms — builders as nodes", "what": "WO-mesh-comms-builders-as-nodes-define — DEFINE: Mesh Comms — builders as nodes", "why": "North-Star chunk: Mesh Comms — builders as nodes. Every builder walks around with a radio and becomes a NODE. Explore reticulum/LoRa (range is the problem). A SIP-calling VPS telephone system is the backbone of everything; an offl ENABLES: completing this turns 'Mesh Comms — builders as nodes' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/mesh-comms-builders-as-nodes.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-music-every-forge", "file": "WO-music-every-forge.md", "title": "WO-music-every-forge — music becomes a layer across ALL 7 forges, not just Signal", "what": "Commander S412: 'music's gonna end up being part of every other forge.' Make the music widget/ability mountable in every forge (Reality/Creation/Signal/Guardian/Wealth/Character/Infinity) — each forge gets its frequency + a music surface. Music is a cross-cutting shell ability, not a page.", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-newsreader-demo-fallback", "file": "WO-newsreader-demo-fallback.md", "title": "WO-newsreader-demo-fallback — give widget-news-reader an offline demo so the crew can audit it", "what": "WO-newsreader-demo-fallback — give widget-news-reader an offline demo so the crew can audit it", "why": "news-reader is mount-C (demoData missing) so it can't be cheap-audited; add demo data to flip it to B. DO: add a non-null demoData fixture + wire renderCard to use it when the atom-feed fetch 401s.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-offerings-polish-johnny-rachel-l2", "file": "WO-offerings-polish-johnny-rachel-l2.md", "title": "WO — Polish the offerings (L1/L2/L3 sale-ready) + finish the Johnny/Rachel Level-2 suite", "what": "WO — Polish the offerings (L1/L2/L3 sale-ready) + finish the Johnny/Rachel Level-2 suite", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-opensource-electrical-devices-marketplace", "file": "WO-opensource-electrical-devices-marketplace.md", "title": "WO-opensource-electrical-devices-marketplace — Aggregate open-source electrical devices (from Instagram) into ONE storefront on ARAYA OS", "what": "WO-opensource-electrical-devices-marketplace — Aggregate open-source electrical devices (from Instagram) into ONE storefront on ARAYA OS", "why": "There's a wave of open-source electrical / hardware devices all over Instagram with no unified place to buy them — makers are scattered, buyers can't find them, and none of it is monetized. Aggregating them into ONE spot on ARAYA OS gives makers distribution + a payout, gives buyers a trusted catalog, and feeds the platform's 20%-cut engine. It's also the sourcing arm for Guardian Forge (see WO-guardian-forge-opensource-tools). DO: Build a sourced list of open-source electrical-device makers seen on Instagram, run outreach to invite them to list, and stand up a single catalog storefront on ARAYA OS that sells through the seller funnel. See RING 3.", "where": "Build INTO the ONE shell (storefront widget/page in pulse), reuse the seller funnel for checkout — do not build a second cart.", "who": "COMMANDER-authored; maker-facing outreach; buyer-facing catalog is public. Unclaimed. SPAWN: WO-guardian-forge-opensource-tools (sibling), WO-health-detox-frequency-tek-marketplace (sibling), buyer-side cart polish. RELATED: WO-seller-onboarding-cart-funnel, project_unite-the-movement-blueprint, project_offerings-consolidation, project_creator-tools-platform-vision, project_affiliate-fractal-system, project_ark-electronics-kit SOURCE: Commander dictation S426 — \"contacting all open source electrical devices I'm seeing everywhere on Instagram to sell in 1 spot.\"", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-orphan-widgets-decision", "file": "WO-orphan-widgets-decision.md", "title": "WO-orphan-widgets-decision — Decide the 3 orphan widgets: load, archive, or finish (analytics / news-reader / voice)", "what": "WO-orphan-widgets-decision — Decide the 3 orphan widgets: load, archive, or finish (analytics / news-reader / voice)", "why": "Widget ledger S420b: 3 widget files exist that the shell never loads — dead or stranded code, worst gap scores in the seed pyramid (15-17). Every census cycle recounts them until decided. DO: Commander decides per orphan: (a) register + load it (V1 row + script tag), (b) archive to components/widgets/_archive/, or (c) card it for finishing. widget-voice may be superseded by the araya-voice.html text fallback shipped S420b.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-p4-store-owner-clone", "file": "WO-p4-store-owner-clone.md", "title": "WO-p4-store-owner-clone — P4 clone/customize/publish rebuilt on the canonical pack registry", "what": "WO-p4-store-owner-clone — P4 clone/customize/publish rebuilt on the canonical pack registry", "why": "PR #889 (S416, closed S453 by merge-captain triage) built the whole flow on a NEW parallel Supabase schema — a no-8th-copy violation of CANONICAL_STORES.md (packs canonical = DNA/PACK_REGISTRY.json, frozen S451). Capability still wanted per the locked tier map; the branch (opencode-26-store-clone) is preserved as reference but must be rebuilt on the canonical stores, not merged.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pack-backlog-widgets", "file": "WO-pack-backlog-widgets.md", "title": "WO-pack-backlog-widgets — Build the pack-backlog widgets", "what": "WO-pack-backlog-widgets — Build the pack-backlog widgets", "why": "S448 ran the pack bridge live — 15 grants landed in widget_grants, but ~half of every owned pack resolved to NOTHING because the widget doesn't exist in widget_catalog. Johnny/Rachel/Odin are missing real business surfaces (files, case, earn, booking, etc.). Each is one tracked object here, not 10 scattered docs. BACKLOG (ranked by how many owned packs request it — from apply-pack-v2 dry-run): - files (4 packs) - case (3 packs) - earn (3 packs) # note: 'earn' historically aliased to widget-store — confirm one canonical id - links (3 packs) - projects (2 packs) - workdesk (2 packs) - scorecard (2 packs) - vault (1 pack) # NOTE: widget-vault already exists as an ORPHAN file per WIDGET_LEDGER — likely activation-only - booking (1 pack) # Rachel's ArtWorks Land Lab core surface - doc (1 pack) (DOORS, not widgets — do NOT build as widgets: reception, page. They route to receptionist.html / builder page.) DO: 1. TRIAGE FIRST (this shrinks the job): for each backlog id, check components/widgets/ + DNA/WIDGET_LEDGER.csv. Split into (A) file EXISTS but not in widget_catalog → just needs a catalog row + active=true (activation), vs (B) truly unbuilt → needs a widget built to GOLD_STANDARD (DNA/WIDGET_FACTORY.md). 2. For (A) activation: insert widget_catalog row (widget_id bare, title, pitch, cost_class, active=true), verify it renders. 3. For (B) build: build per WIDGET_FACTORY.md, add catalog row, wire into shell. 4. Reconcile the 'earn' vs 'widget-store' alias — pick ONE canonical widget_id, update ALIASES in apply-pack-v2.py. 5. Re-run `C:\\Python313\\python.exe DNA/apply-pack-v2.py --commit` — each newly-catalogued widget now grants automatically to the packs that want it (idempotent; only writes the new ones). Verify grants land by readback.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pack-owner-toggle-collapse", "file": "WO-pack-owner-toggle-collapse.md", "title": "WO — Pack owners: collapse the 3-lane mode dial to My Cockpit / Public preview", "what": "WO — Pack owners: collapse the 3-lane mode dial to My Cockpit / Public preview", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pattern-theory-posters", "file": "WO-pattern-theory-posters.md", "title": "WO — Pattern Theory Posters (Class 016 product + \"upgrade every character poster\")", "what": "WO — Pattern Theory Posters (Class 016 product + \"upgrade every character poster\")", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-communication", "file": "WO-pillar-communication.md", "title": "WO-pillar-communication — SEEDABLE BUSINESS: mesh radios → off-grid comms network (Pillar 6 of 13)", "what": "WO-pillar-communication — SEEDABLE BUSINESS: mesh radios → off-grid comms network (Pillar 6 of 13)", "why": "When the grid/cell network fails, coordination fails — you can't run water/energy/security response without comms. Meshtastic (LoRa) nodes are cheap (~$25-40), need no infrastructure, and this is an ACTIVE build in sovereignty-hub (issue #5 mesh bridge). Seed→scale: sell/configure radios → run relay nodes → a resilient community mesh with offline messaging + AI-over-LoRa. SEED (~1 person): Buy/flash/configure Meshtastic radios and sell them set-up-and-ready to neighbors. Start cost = a few radios (~$100-150 for 3-4 units). SCALE (community-critical): A community mesh — solar-powered relay nodes on high points, offline group messaging, emergency broadcast, and the AI-over-LoRa bridge — the comms backbone every other pillar coordinates over. REVENUE (C6): SEED — a $30 radio sold configured-and-ready for $70-90 (setup labor is the value-add). Setup service $20-40/unit. 10 units/mo = ~$500-800. SCALE — network membership ($5-10/mo per node for relay/maintenance access — recurring), relay-node install ($100-300), emergency-broadcast service for the community. Best margin: the setup service (labor on cheap hardware); best recurring: network membership. GOVERNANCE MODULE: Seed = member owns their radios. Scale = the mesh becomes a \"comms co-op\" node — relay-host members get credits in the pillar ledger; channel/frequency/moderation rules and the emergency-broadcast protocol are set in the charter (who can trigger an all-node alert = a critical governance decision); abuse/spam on the mesh routes to the Governance dispute module. Encryption keys managed per the No-Single-Capture doctrine. TIES: ENERGY (solar relay nodes — direct dependency) · SECURITY (emergency coordination, alerts) · GOVERNANCE (voting/announcements can ride the mesh) · KNOWLEDGE (AI-over-LoRa serves offline knowledge) · every pillar coordinates over comms in a crisis. DO: (1) Publish the Meshtastic setup guide + BOM from Pillar 6 (leverage active issue #5). (2) Member flashes/configures 3-4 radios, sells set up to neighbors. (3) Stand up a radio store + network-membership page (Trade marketplace). (4) Sell to 5 neighbors, get 3 nodes talking on one channel. (5) Log the comms-co-op charter stub + broadcast protocol.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-culture", "file": "WO-pillar-culture.md", "title": "WO-pillar-culture — SEEDABLE BUSINESS: music/story/events studio → the reason the community holds (Pillar 13 of 13)", "what": "WO-pillar-culture — SEEDABLE BUSINESS: music/story/events studio → the reason the community holds (Pillar 13 of 13)", "why": "Culture is why a community is worth surviving FOR — the pillar that turns a group of self-sufficient households into a people. It's also the growth engine: music, story, and events are the top-of-funnel that brings new members in (ties to the influencer/podcast push). Least \"survival-critical\" in an acute sense, but the pillar that prevents the community from dissolving once fed and safe. Seed→scale: content/music + one event → a studio + event series → the community's media + identity engine. SEED (~1 person): Produce music (the ElevenLabs music-generation pipeline is LIVE), art, or story content + host one community event (open mic, story night, market-day entertainment). Start cost = ~$0-100 (existing pipeline + a venue that's a living room/park). SCALE (community-critical): A media + events engine — a studio, a podcast/YT channel (the funding-plan engine), event series, and the shared story/brand that gives the community identity and recruits new members. REVENUE (C6): SEED — custom songs/content ($20-100/piece via the live music pipeline), event tickets/donations ($5-15/head), merch/art sales. SCALE — content channel (podcast/YT ad + sponsor revenue — the existing house→podcast funding plan), event series, brand/merch, paid commissions, patron/membership ($5-15/mo). HONESTY: culture monetizes UNEVENLY — most content earns little; a few hits + events + the channel carry it. Best margin: digital content (music pipeline = near-zero marginal cost); best recurring: patron membership + channel revenue. It also has the highest INDIRECT value: it feeds the funnel that grows every other pillar's customer base. GOVERNANCE MODULE: Seed = member owns their creative work + IP. Scale = a shared studio/brand becomes a \"culture co-op\" node — creators retain IP but licensing/revenue-share for shared-brand work is a charter clause; event proceeds split (creator/community-fund) voted 1-member-1-vote; content standards (what represents the community) + brand use are charter clauses; disputes over credit/royalties route to Governance. Balance the gift-economy ethos (free community events) with sustainability (paid channel/commissions). TIES: KNOWLEDGE (story is how knowledge/values transmit) · TRADE (merch/tickets sell through marketplace) · COMMUNICATION (events announced over the mesh) · every pillar's story gets told here; Culture is the funnel that recruits members INTO all 12 other pillars. DO: (1) Package a content/music offering using the LIVE music-generation pipeline (songs-table + player already shipped) from Pillar 13. (2) Member produces 3 pieces + plans one community event. (3) Stand up a content-sales + event-ticket page (Trade marketplace). (4) Sell 5 pieces or host one event with real attendance. (5) Log the culture-co-op charter stub + IP/revenue-share clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-energy", "file": "WO-pillar-energy.md", "title": "WO-pillar-energy — SEEDABLE BUSINESS: battery reconditioning → the block's microgrid (Pillar 4 of 13)", "what": "WO-pillar-energy — SEEDABLE BUSINESS: battery reconditioning → the block's microgrid (Pillar 4 of 13)", "why": "Energy is the multiplier for every other pillar — water pumps, grow lights, refrigeration (food+medicine), comms all die without power. Battery reconditioning turns free/cheap scrap (dead 18650s, car/forklift batteries) into sellable storage — high margin from a near-zero material cost. Seed→scale: reconditioned power banks → solar-kit installs → a shared microgrid. SEED (~1 person): Recondition salvaged 18650 cells / lead-acid batteries into power banks + small solar phone/light kits. Start cost < $250 (a charger/analyzer + salvage cells often free). SCALE (community-critical): Solar-kit installs and a battery-bank microgrid that powers critical loads (well pump, fridge, comms hub) through outages — the member becomes the block's power keeper. REVENUE (C6): SEED — a reconditioned power bank costs ~$5-10 in salvaged cells, sells $40-80 (5-8x). Small solar+battery light kit: ~$30 cost → $90-120. 10 units/mo = ~$500-900. SCALE — solar-kit installs ($300-2000 per home, labor + parts markup), microgrid membership ($20-40/mo for backup-power access), EV/tool charging service. Best margin: reconditioned banks (salvage input); best recurring: microgrid-access membership. GOVERNANCE MODULE: Seed = member owns their gear. Scale = a shared battery bank/microgrid becomes an \"energy co-op\" node — capital contributors get proportional shares in the pillar ledger; load-priority rules (who gets power in a shortage — medical first) are set in the charter and voted 1-member-1-vote; safety (fire/electrical) is a mandatory certified-install clause; billing disputes route to the Governance module. TIES: WATER (pumps/UV) · FOOD (refrigeration, grow lights) · MEDICINE (refrigeration for meds, PEMF devices) · COMMUNICATION (powers the mesh hub) · MANUFACTURING (charges tools) — Energy underwrites nearly every pillar. DO: (1) Publish the reconditioning + small-solar-kit BOM from Pillar 4. (2) Member reconditions a batch, builds 2-3 kits. (3) Stand up a store/service page (Trade marketplace). (4) Sell to 5 neighbors; note who wants microgrid backup. (5) Log the energy-co-op charter stub + safety clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-food", "file": "WO-pillar-food.md", "title": "WO-pillar-food — SEEDABLE BUSINESS: from one seed tray to the block's food (Pillar 2 of 13)", "what": "WO-pillar-food — SEEDABLE BUSINESS: from one seed tray to the block's food (Pillar 2 of 13)", "why": "The most literal seed→survival pillar. A tray of microgreens goes seed→harvest in 7-10 days, so cash comes in the FIRST week. Food is the second thing a community dies without. Seed→scale: one microgreen tray → weekly herb/greens subscription → aquaponics + preservation that carries households through a supply-chain break. SEED (~1 person): One shelf of microgreen/herb trays (sunflower, pea, basil). Seed-to-sale in ~10 days. Start cost < $150 (trays, seed, soil, a shelf). SCALE (community-critical): A neighborhood CSA — weekly veg/herb boxes, an aquaponics loop (fish + greens), and a preservation kitchen (canning/drying) so food doesn't spike-and-rot. The member becomes the block's grower. REVENUE (C6): SEED — microgreens are the highest $/sqft crop: a $0.50 tray of seed yields ~$20-30 of greens; restaurants/neighbors pay $20-30/lb. 20 trays/week on a rotation = ~$300-500/mo at near-zero marginal cost. Add a $25-40/mo weekly herb-box subscription. SCALE — CSA boxes at $30-50/week x 15 households = $450-750/week; preservation/value-add (dried herbs, canned goods) sells at 4-6x raw cost. Best margin: microgreens (fastest cycle) at seed, CSA subscription at scale (predictable recurring). GOVERNANCE MODULE: Seed = member owns their grow. Scale = when land/water/aquaponics is shared, it becomes a \"grow co-op\" node — contributors of land/labor/capital get proportional shares recorded in the pillar ledger; harvest-split and pricing decided by 1-member-1-vote on the co-op board; crop-failure/liability disputes route to the Governance dispute module. Food-safety standard is a mandatory clause in the charter. TIES: WATER (irrigation/aquaponics is water-hungry — pair with Pillar 1) · ENERGY (grow lights, pumps) · MEDICINE (nutrition = preventive health) · TRADE (CSA sells through marketplace) · KNOWLEDGE (grow guides) · CULTURE (community harvest events). DO: (1) Publish the microgreen + herb starter BOM from Pillar 2. (2) Member sets up one grow shelf, runs one 10-day cycle. (3) Stand up a CSA/herb-box subscription page on the Trade marketplace. (4) Sell the first harvest to 5 neighbors; enroll 2 on the weekly box. (5) Log the grow-co-op charter stub.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-governance", "file": "WO-pillar-governance.md", "title": "WO-pillar-governance — SEEDABLE BUSINESS: charter-as-a-service → the community operating system (Pillar 11 of 13)", "what": "WO-pillar-governance — SEEDABLE BUSINESS: charter-as-a-service → the community operating system (Pillar 11 of 13)", "why": "Commander explicitly flagged \"governance modules.\" Governance is the pillar the other 12 all DEPEND ON — every pillar card above ends with \"route disputes to the Governance module\" and \"voted 1-member-1-vote.\" Without a shared, trusted way to decide/own/resolve, every co-op fractures the moment there's money or conflict. This pillar productizes the governance modules the other 12 reuse. Seed→scale: facilitate one charter → run voting/dispute for a few co-ops → the community's operating system. SEED (~1 person): A facilitator who helps a group write its charter (ownership shares, decision rules, dispute process) using standard templates, and sets up a simple voting + dispute board. Start cost = ~$0 (templates + a shared doc/board). SCALE (community-critical): The shared governance stack — charter templates, a voting system, a dispute-resolution process, and the pillar-ledger of ownership/shares — that all 12 other co-ops plug into. The member becomes the community's clerk/facilitator. REVENUE (C6): SEED — charter facilitation flat fee ($75-200 per group), dispute-mediation fee ($30-75/session). SCALE — governance-platform subscription per co-op ($10-25/mo for hosted voting + ledger — recurring across all 12 pillars' co-ops), mediation retainer, election/vote administration. Best leverage: like Trade, its revenue is a small recurring fee across EVERY other pillar's co-op — it compounds. HONESTY: governance is a HARD sell as a standalone product (people don't pay for rules until conflict hits) — see RISK. It monetizes best BUNDLED into every other co-op's setup, not sold alone. GOVERNANCE MODULE (recursive — this pillar IS the module): The governance layer governs itself with the same primitives — the facilitator is NOT the decider (No-Single-Capture: no single party controls the vote or the ledger); charter changes require supermajority; the dispute process has an appeal path; the pillar-ledger of ownership is transparent to all members. This is the reference implementation the other 12 point to. TIES: ALL 12 other pillars route their disputes, votes, and ownership records here — it's the dependency named in every other card. Twins with SECURITY (external legal defense) — internal rules + external shield are two sides of the same coin. Feeds the pillar-ledger that TRADE and every co-op uses. DO: (1) Publish the charter + voting + dispute-resolution templates from Pillar 11 (these are what every other card's \"charter stub\" points to — build them FIRST). (2) Member facilitates ONE real group charter (start with one of the other pillar's seed co-ops). (3) Set up a simple voting + dispute board for that group. (4) Run one real vote or resolve one real dispute. (5) Establish the shared pillar-ledger format.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-knowledge", "file": "WO-pillar-knowledge.md", "title": "WO-pillar-knowledge — SEEDABLE BUSINESS: offline AI + how-to library → the community's brain (Pillar 12 of 13)", "what": "WO-pillar-knowledge — SEEDABLE BUSINESS: offline AI + how-to library → the community's brain (Pillar 12 of 13)", "why": "Knowledge is how each pillar teaches the next member to start — the how-to library IS the seed-dispersal mechanism for all 13. And offline AI (the ~$75 Pi 5 stack in sovereignty-hub) means the community keeps its assistant/knowledge even when internet dies. A member can sell a configured offline-AI box + a course THIS week. Seed→scale: sell/setup offline-AI boxes + courses → a knowledge library → the AI-over-everything backbone (ties to ARAYA + the case-RAG/law-school work). SEED (~1 person): Assemble + configure Pi 5 offline-AI boxes (Whisper + Ollama + Kokoro, ~$75 parts) and sell them ready-to-run, plus a paid \"how to run your own AI\" course. Start cost = a couple Pi boxes (~$150-200). SCALE (community-critical): The community brain — a shared offline knowledge library (blueprints for all 13 pillars, case-law DB, Pattern Theory), AI assistants per household, and the training pipeline that onboards every new pillar-seed member. REVENUE (C6): SEED — a $75 offline-AI box sold configured for $180-250 (setup + curated model/knowledge pack is the value), plus a course at $30-80/head. 8 boxes + one course cohort/mo = ~$700-1200. SCALE — knowledge-library subscription ($5-15/mo — recurring), per-pillar training courses (each pillar needs onboarding content), AI-assistant hosting, the coach/LLM-course deal (existing — coach on board). Best margin: courses/content (build once, sell many); best recurring: the library subscription + the box's knowledge-pack updates. GOVERNANCE MODULE: Seed = member owns their boxes/courses. Scale = the knowledge library becomes a \"commons co-op\" node — content is open/shared per the sovereignty-hub open-source ethos (gift-economy balance — see Commander's gift-vs-paid doctrine); contributors of blueprints/courses get attribution + revenue-share credits in the pillar-ledger; what stays free vs paid is a charter decision (blueprints free, curated/live training paid); accuracy/quality disputes route to Governance. No-Single-Capture on the knowledge itself — no one owns the commons. TIES: ALL 12 other pillars need Knowledge to teach their seed (the how-to library is the onboarding for every pillar) · COMMUNICATION (AI-over-LoRa serves knowledge offline) · SECURITY (case-law DB, issue #4) · MANUFACTURING (design-file library). Knowledge is how the whole system self-replicates (3→7→13→∞ needs a teacher). DO: (1) Publish the offline-AI box BOM + \"run your own AI\" course from Pillar 12 (leverage the existing offline AI stack + issue #3 Kokoro on Pi). (2) Member assembles + configures 2 boxes, drafts the course. (3) Stand up a store + course page (Trade marketplace). (4) Sell 3 boxes or run one course cohort. (5) Log the commons-co-op charter stub + free-vs-paid clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-manufacturing", "file": "WO-pillar-manufacturing.md", "title": "WO-pillar-manufacturing — SEEDABLE BUSINESS: 3D-print/fab-on-demand → the block's factory (Pillar 7 of 13)", "what": "WO-pillar-manufacturing — SEEDABLE BUSINESS: 3D-print/fab-on-demand → the block's factory (Pillar 7 of 13)", "why": "Manufacturing is the pillar that makes the OTHER pillars' parts — filter housings, battery holders, radio mounts, replacement gears. Supply chains break; a local printer/fab shop means a broken part is a same-day fix, not a two-week wait. A single $200-400 printer + free STL files is a real business the first week. Seed→scale: print-on-demand → tool repair → a full fab shop (CNC, injection, casting). SEED (~1 person): One 3D printer running print-on-demand jobs (repair parts, custom brackets, the other pillars' components) from free/library STLs. Start cost = one printer (~$200-400). SCALE (community-critical): A community fab shop — multiple printers, CNC, casting, tool repair — that supplies replacement parts and custom builds for all 13 pillars; the member becomes the block's maker-in-chief. REVENUE (C6): SEED — print jobs priced at material + machine-time + labor: a part costing ~$1 in filament sells $8-25 depending on complexity (huge margin on labor/design). Repair jobs $15-40. 20 jobs/mo = ~$400-800. SCALE — production runs for the other pillars (filter parts, radio mounts — internal B2B), custom fabrication contracts, a design-file library subscription. Best margin: custom/design work (labor); best recurring: internal supply to the other 12 pillars + a parts subscription. GOVERNANCE MODULE: Seed = member owns their printer. Scale = a shared fab shop becomes a \"maker co-op\" node (twins with Shelter's workshop) — equipment donors get machine-time credits in the pillar ledger; a maintenance/filament fund from job margins is spent 1-member-1-vote; IP/design-ownership rules (who owns a custom design) and job-priority (survival parts first) are charter clauses; disputes route to Governance. TIES: SHELTER (shares the workshop — near-twin) · WATER/ENERGY/COMMUNICATION/MEDICINE (prints their housings, mounts, holders, device parts — Manufacturing is the parts-supplier to nearly every pillar) · KNOWLEDGE (design-file library) · TRADE (sells through marketplace). DO: (1) Publish the print-on-demand starter guide + a starter STL library from Pillar 7. (2) Member sets up one printer, runs 3 real jobs (including one part FOR another pillar). (3) Stand up an order/quote page (Trade marketplace). (4) Fill 5 neighbor jobs. (5) Log the maker-co-op charter stub + IP clause.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-medicine", "file": "WO-pillar-medicine.md", "title": "WO-pillar-medicine — SEEDABLE BUSINESS: herbal apothecary + first-aid readiness (Pillar 5 of 13)", "what": "WO-pillar-medicine — SEEDABLE BUSINESS: herbal apothecary + first-aid readiness (Pillar 5 of 13)", "why": "Health is survival-critical but this is the HARDEST seed to keep legal (see RISK) — you cannot diagnose/treat without licensure. The safe, real seed is wellness/topical herbal products + first-aid kit assembly + training, NOT medical care. Grown herbs (tie to Food pillar) become salves/teas/tinctures. Seed→scale: apothecary products → first-aid kits + CPR/first-aid classes → a stocked community readiness cache. SEED (~1 person): Salves, teas, tinctures from grown/foraged herbs (topical/wellness only) + assembled first-aid kits. Start cost < $150 (jars, base oils, herbs from the Food pillar). SCALE (community-critical): A stocked first-aid/readiness cache + trained responders (certified via real orgs) + telehealth-referral hub — the community's health-preparedness backbone. NOT a substitute for licensed care. REVENUE (C6): SEED — herbal salve costs ~$2-3 to make, sells $12-18 (5x); tinctures $15-30; assembled first-aid kit ~$15 cost → $35-50. First-aid/CPR class $25-50/head. 15 products + one class/mo = ~$400-700. SCALE — kit subscriptions (refresh expiring supplies, $10-15/mo recurring — consumables again), class series, readiness-cache membership. Best margin: apothecary products; best recurring: kit-refresh subscription (supplies expire → built-in repeat). GOVERNANCE MODULE: Seed = member owns their apothecary. Scale = a shared readiness cache becomes a \"health-readiness co-op\" node — the charter carries a HARD compliance clause (no medical/diagnostic claims, licensed-only for care, product-liability waiver, cottage-food/cosmetic labeling rules). Cache-stocking decisions voted 1-member-1-vote; a designated compliance steward (not majority) can veto anything that crosses into practicing medicine. Disputes route to Governance. TIES: FOOD (herbs are grown crops — direct input) · WATER (clean water prevents most illness — upstream) · KNOWLEDGE (training/guides) · ENERGY (refrigeration for meds) · SECURITY (legal/compliance overlap). DO: (1) Publish the apothecary + first-aid-kit BOM from Pillar 5 WITH the compliance clause up front. (2) Member makes a product batch (topical/wellness only) + assembles 3 kits. (3) Stand up a store/class page (Trade marketplace) with compliant labeling. (4) Sell to 5 neighbors or run one first-aid class. (5) Log the co-op charter stub + compliance clause + waiver.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-shelter", "file": "WO-pillar-shelter.md", "title": "WO-pillar-shelter — SEEDABLE BUSINESS: tool library → the block's build crew (Pillar 3 of 13)", "what": "WO-pillar-shelter — SEEDABLE BUSINESS: tool library → the block's build crew (Pillar 3 of 13)", "why": "Shelter is survival-critical #3 — a roof that fails in winter kills. Most households can't afford or store tools they use twice a year; a shared library monetizes idle tools immediately and becomes the crew that keeps everyone's shelter standing. Seed→scale: a shelf of lent tools → a workshop membership → a paid build/repair crew. SEED (~1 person): A shelf of 20-30 quality tools (drills, saws, ladders) lent by the day. Start from tools the member already owns — near-zero cash start. SCALE (community-critical): A community workshop + weatherization/repair crew that keeps roofs, insulation, and structures sound; tiny-home build support for members who need housing. REVENUE (C6): SEED — tool rental at $5-15/day/tool + a $10-20/mo library membership (unlimited borrows). 25 members = $250-500/mo recurring with tools you already own. SCALE — workshop bench-time rental ($15-25/hr), paid repair/weatherization jobs (labor $40-75/hr + materials markup), tiny-home build contracts (project-based, $2-15k). Best margin: the membership (pure recurring on sunk-cost tools); biggest ticket: build/weatherization labor at scale. GOVERNANCE MODULE: Seed = member owns the tools, sets lending rules. Scale = a shared workshop becomes a \"maker co-op\" node — tool donors get borrowing credits recorded in the pillar ledger; a tool-replacement fund is funded from membership dues, spent by 1-member-1-vote; damage/liability disputes route to the Governance dispute module (waiver clause mandatory in the charter). TIES: MANUFACTURING (workshop shares space/tools with 3D-print/fab — near-twin pillar) · ENERGY (weatherization cuts energy load) · TRADE (job booking through marketplace) · KNOWLEDGE (build guides) · TRANSPORTATION (tool/material hauling). DO: (1) Publish the tool-library starter list + lending rules from Pillar 3. (2) Member catalogs 20-30 tools, sets rental + membership price. (3) Stand up a booking/membership page (Trade marketplace). (4) Lend to 5 neighbors; enroll 2 on membership. (5) Log the maker-co-op charter stub + waiver.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-trade", "file": "WO-pillar-trade.md", "title": "WO-pillar-trade — SEEDABLE BUSINESS: the marketplace itself → the community economy (Pillar 10 of 13)", "what": "WO-pillar-trade — SEEDABLE BUSINESS: the marketplace itself → the community economy (Pillar 10 of 13)", "why": "Trade is the META-pillar — it's how every other pillar turns product into income. A community that produces water/food/energy but has no way to exchange it starves in a different way. The marketplace is the platform play: the member who runs it earns a cut of EVERY pillar's sales. Seed→scale: a listing board + monthly market day → a full local marketplace with barter credits → the community currency/economy layer. SEED (~1 person): A simple listing board (or a recurring physical market day) where the other pillars' members sell. Start cost = ~$0 (a page + a parking lot). SCALE (community-critical): The full local economy — online marketplace + barter-credit system + market days + a local unit of account (ties to the mission-tokenization/gold-back work). The member becomes the market-maker who takes a small cut of community-wide commerce. REVENUE (C6): SEED — listing/transaction fee (2-5% of each sale) OR a flat vendor fee for market-day booths ($10-25/booth). Even 10 vendors x $200 sales x 3% = modest, but it SCALES with every pillar's growth. SCALE — marketplace transaction fees across all 12 producing pillars (the affiliate/fractal cut already in the system — 20% presence cut model), premium vendor storefronts, barter-credit float, market-day sponsorships. Best margin/leverage: the platform cut — it compounds as the other 12 pillars grow. This is the pillar whose revenue is a % of ALL the others. GOVERNANCE MODULE: Seed = member operates the board. Scale = the marketplace becomes a \"commerce co-op\" node — vendors get a voice in fee structure (fee changes voted 1-member-1-vote so the market-maker can't gouge), a listed dispute/refund policy, quality/fraud standards enforced with the No-Single-Capture doctrine (no single party controls the money rail). Barter-credit issuance rules are a hard charter clause (prevent inflation). Disputes route to Governance; the fee itself is capped in the charter. TIES: ALL 12 other pillars sell through Trade (it's the common sales channel — every other card's DO step lands here) · TRANSPORTATION (moves the goods) · GOVERNANCE (fee/dispute rules) · KNOWLEDGE (reputation/reviews). Trade is the hub every spoke connects to. DO: (1) Stand up the marketplace/barter board (reuse the existing Trade marketplace + affiliate/fractal system). (2) Onboard the first 3 pillar-vendors (e.g., Water filters, Food boxes, Manufacturing prints). (3) Run one transaction end-to-end (or one market day). (4) Take the first platform fee. (5) Log the commerce-co-op charter stub + fee cap.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-transportation", "file": "WO-pillar-transportation.md", "title": "WO-pillar-transportation — SEEDABLE BUSINESS: mobile repair/diagnostics → community fleet (Pillar 9 of 13)", "what": "WO-pillar-transportation — SEEDABLE BUSINESS: mobile repair/diagnostics → community fleet (Pillar 9 of 13)", "why": "Without transport, no food/materials move and members can't get to work/court/care. A $30 OBD2 scanner reads the fault codes that dealers charge $120 to read — instant value. Mobile repair needs no shop. Seed→scale: diagnostics + basic repair → propane/alt-fuel conversion → a shared community fleet (tools, hauling, rides). SEED (~1 person): Mobile OBD2 diagnostics + basic repair (brakes, fluids, batteries) at the customer's driveway. Start cost < $200 (scanner + hand tools, often already owned). SCALE (community-critical): A shared fleet + repair co-op — pooled vehicles for hauling/rides, propane/alt-fuel conversions, and a repair shop that keeps the block's vehicles running when parts/gas get scarce. REVENUE (C6): SEED — diagnostic scan $30-60 (vs dealer $120), basic repair labor $40-75/hr + parts markup. Mobile = no shop overhead. 15 jobs/mo = ~$500-900. SCALE — fleet-share membership ($30-60/mo for pooled-vehicle access — recurring), propane-conversion jobs ($500-2000), hauling/delivery service, a parts-buying co-op. Best margin: diagnostics (labor on a cheap tool); best recurring: fleet-share membership. GOVERNANCE MODULE: Seed = member owns their tools. Scale = a shared fleet becomes a \"mobility co-op\" node — vehicle contributors get usage credits in the pillar ledger; pooled-vehicle scheduling, maintenance-fund spending, and priority-use (medical/court trips first) are charter clauses voted 1-member-1-vote; accident/liability disputes route to Governance (insurance + waiver mandatory clauses). TIES: TRADE (moves goods to market — direct dependency) · FOOD (harvest/CSA delivery) · ENERGY (EV charging, alt-fuel) · MANUFACTURING (prints/fabs repair parts) · SECURITY (rides to court). Transportation is the circulatory system between pillars. DO: (1) Publish the mobile-diagnostics starter guide + tool list from Pillar 9. (2) Member does 3 real diagnostic/repair jobs. (3) Stand up a booking page (Trade marketplace). (4) Serve 5 neighbors, note who wants fleet-share. (5) Log the mobility-co-op charter stub + insurance/waiver clauses.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-pillar-water", "file": "WO-pillar-water.md", "title": "WO-pillar-water — SEEDABLE BUSINESS: clean water as a service (Pillar 1 of 13)", "what": "WO-pillar-water — SEEDABLE BUSINESS: clean water as a service (Pillar 1 of 13)", "why": "Water is survival-critical #1 — no clean water = no community in days. The seed is the lowest-capital, fastest-to-cash pillar: a $30 bucket + filter element resells for $60-90, and everyone already needs it. Seed→scale: one filter sold this week → a filter-of-the-month + element-replacement subscription → shared rain-catch + purification for a street when the tap fails. SEED (~1 person): Build one gravity filter from the BOM (food-grade bucket + ceramic/carbon element). Sell/deliver to 5 neighbors. Total start cost < $200. SCALE (community-critical): A local water backbone — rain collection, storage, and purification that keeps a block alive through an outage; the member becomes the \"water keeper\" with recurring element supply. REVENUE (C6): SEED — unit sale, ~$30 cost → $60-90 price (2-3x markup), plus $8-12/mo element-replacement subscription per household (elements need swapping every 3-6 mo → recurring by design). SCALE — shared-system install fee ($200-800 per block) + ongoing purification/testing service ($15-25/household/mo). 10 households on element subs = ~$100/mo passive at seed; a serviced block = $200-400/mo. Highest margin: the recurring element sub, because it's a consumable. GOVERNANCE MODULE: Charter template from Pillar 11 (Governance). Seed = sole-proprietor member owns their kit. Scale = when a shared system serves >3 households, it converts to a \"water co-op\" node — households buying in get 1 vote each on maintenance-fund spending; disputes (quality, billing) route to the community dispute-resolution module. Ownership recorded in the pillar ledger; the keeper is paid a service wage, not rent-seeking. TIES: ENERGY (pumps/UV purification need power) · MEDICINE (waterborne-illness prevention is the #1 health lever) · GOVERNANCE (co-op charter + disputes) · KNOWLEDGE (BOM/build docs) · TRADE (sells through the marketplace). DO: (1) Publish the water micro-utility BOM + build video from sovereignty-hub Pillar 1. (2) Stand up a one-page order form (Trade pillar marketplace) with unit price + element subscription tier. (3) Member builds ONE filter, sells to 5 households, enrolls at least 2 on element subs. (4) Log the co-op charter stub even at seed (owner = the member).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-poster-prompting-system", "file": "WO-poster-prompting-system.md", "title": "WO — Poster Prompting System (find the proven method, so we make GREAT posters not junk)", "what": "WO — Poster Prompting System (find the proven method, so we make GREAT posters not junk)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-pr3-bus-command-center", "file": "WO-pr3-bus-command-center.md", "title": "WO-pr3-bus-command-center — Operation Bus Command Center: capture + build spec", "what": "WO-pr3-bus-command-center — Operation Bus Command Center: capture + build spec", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-rail-sectioning", "file": "WO-rail-sectioning.md", "title": "fix the 17-widget business-rail squish (section it, or add business sub-modes)", "what": "S410 loaded the full approved cockpit onto KORPAKS.business — 17 ids on ONE flat rail: leads,orders,booking,revenue,comms,messages,calls,contacts,case,caseboard,casetimeline,todos, projects,agents,calendar,earn,page. It works, but it's dense — the exact \"16-widget squish\" S377 warned about, now real on mobile width.", "why": "A rail you have to hunt through isn't a cockpit. The loadout is RIGHT (Commander-approved); the PRESENTATION needs a pass so money/comms/case/build read as groups, not a wall of icons. DO: Pick ONE with Commander (mockup both): (A) SECTION THE RAIL — group headers (💰 Money · 💬 Comms · ⚖️ Case · 🛠️ Build · ⚙️ Utility) in the rail panel. Least disruptive; KORPAKS stays one array, buildRail() renders dividers. (B) BUSINESS SUB-MODES — the mode-dial gains a second ring inside \"business\" (money/comms/case/ build); each sub-mode filters the rail. More powerful, bigger change.", "where": "my/pulse.html — buildRail() (~line 4744), KORPAKS.business (~line 1123), CRChromeV2.setRail(). RAIL_SHORT labels + the curate sheet (renderCurate) may need matching group metadata.", "who": "A Claude window + Commander eyeball (this is a UX call, not a mechanical fix)", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "★ THE WHOLE THING", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-reception-operator-console-repoint", "file": "WO-reception-operator-console-repoint.md", "title": "WO-reception-operator-console-repoint — reception door opens the OPERATOR console, not the sales page", "what": "WO-reception-operator-console-repoint — reception door opens the OPERATOR console, not the sales page", "why": "Wave-3 batch-2 comb (reception C2/C3/C8, money_weight 9) — the reception door is wired to the WRONG canonical. The registered door (my/pulse.html:1195 url:/receptionist.html) opens a 13-section SALES FUNNEL that sells the receptionist to an owner who already owns it; the registry's OWN mission demands an OPERATOR console (\"watch/run MY receptionist: line status, calls caught, 5-W summaries\"). That console ALREADY EXISTS: receptionist-log.html (\"THE LOG\", P1 of DNA/RECEPTIONIST_UX_BLUEPRINT.md, backed by netlify/functions/receptionist-api.mjs) — but it's an ORPHAN (0 inbound HTML links). One widget, two files, door on the wrong one. This is the root of the registry's top work_order for reception. ⚠ PRODUCT DECISION: Commander approved doing this \"next\" (S442) — repointing changes what every business user sees on the reception tile (sales page → their live call log). DO: - Repoint the reception door url (pulse KORPAK_DOORS ~L1195 + the araya-chat door if separate ~:9504) to receptionist-log.html. Verify the operator console loads in the page-door + reads receptionist-api. - Rehome the SALES page (receptionist.html): give it its own sales/L2 door or a marketing route, so the sell-flow isn't lost — it just stops being what an OWNER sees on their own tile. - Wire receptionist-log.html into the registry/inventory (it's currently an orphan) so it stops being one. - Fix the operator surface's card: show live call/lead telemetry (calls caught, line status, minutes) not the static \"tap to open\" placeholder — pairs with WO-ar-receipt-floor + the reception D1 finding.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-reland-s448-code-seams", "file": "WO-reland-s448-code-seams.md", "title": "WO-reland-s448-code-seams — hand-reconcile the code seams of the closed S446-S448 branches", "what": "WO-reland-s448-code-seams — hand-reconcile the code seams of the closed S446-S448 branches", "why": "the stacked S446-S448 branches were closed S453 (merge-captain clearing wave) because their tree lagged everything merged since — a bulk merge would REVERT the identity floor (#1265), XP seals, and chrome standard. Pure additions landed via PR #1267; these seams are the remainder.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-repair-ollama-llama-server", "file": "WO-repair-ollama-llama-server.md", "title": "WO-repair-ollama-llama-server — Repair ollama inference engine (llama-server binary missing) — unblocks the whole free fleet", "what": "WO-repair-ollama-llama-server — Repair ollama inference engine (llama-server binary missing) — unblocks the whole free fleet", "why": "THE fleet blocker (S420, proven live): ollama 0.32.5 api/tags works but every /api/generate fails install-wide with 'llama-server binary not found' — so no local model can generate and the free crew can complete zero code WOs. The WO pipe itself is now fixed and proven; this inference engine is the only wall left. DO: Repair the ollama install so llama-server exists: reinstall/upgrade ollama (the installer bundles the runner) or rebuild the runner; then test qwen2.5-coder:7b and qwen3-coder:30b generate.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-route-git-email-to-100xbuilder", "file": "WO-route-git-email-to-100xbuilder.md", "title": "GitHub email to @100xbuilder.io addresses is failing — fix the inbound routing", "what": "Mail SENT TO @100xbuilder.io addresses (GitHub notifications / verification / invite emails to the git identities like opencode-33@100xbuilder.io) has been FAILING ALL DAY (Commander report, 2026-08-06). Restore inbound email routing so those messages land in an inbox the system actually reads.", "why": "The 100X_DEPLOYMENT git author identity is `opencode-33@100xbuilder.io` (and other opencode-NN@ 100xbuilder.io seats). GitHub sends verification/notification/invite email to those addresses. The existing email pipeline (email_to_case / gmail_sweep) only reads GMAIL accounts (primary + kulture, status OK 15:30). If @100xbuilder.io has no working MX / forwarding into one of those Gmail inboxes, every GitHub email to the domain bounces or black-holes — which blocks git invites, verification, and notifications. This is DNS/provider config (outside the repo), so it needs Commander's domain access.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-seller-onboarding-cart-funnel", "file": "WO-seller-onboarding-cart-funnel.md", "title": "WO-seller-onboarding-cart-funnel — Cart-simple funnel to start selling on ARAYA OS", "what": "WO-seller-onboarding-cart-funnel — Cart-simple funnel to start selling on ARAYA OS", "why": "Selling on ARAYA OS today is scattered across offerings, pages, pricing, and Stripe with no single on-ramp — the friction kills the first sale. A cart-simple, one-path funnel lets any builder list a thing and walk away with a working \"Buy\" link without knowing where anything lives. This is the money on-ramp for the presence-FREE + 20%-cut + $29-hosting model. DO: Build a guided seller funnel that feels like an e-commerce checkout: audit existing pieces first, then a short stepper (what → details → price → payout → publish) that ends in a live, shareable buy link. See RING 3 for the steps.", "where": "The ONE shell (build INTO my/pulse.html, never a standalone page); reuse existing Stripe/offerings/checkout functions for the buyer side.", "who": "Seller-facing, gated to any signed-in builder; payout gated behind Stripe connect. Unclaimed. SPAWN: if it lands — a matching BUYER cart-polish card + an affiliate/XP share-loop card. RELATED: project_offerings-consolidation, project_seven-doors-first-sale, project_builder-onboarding-funnel, project_creator-tools-platform-vision, project_recursive-products-strategy, TIER_AND_AUTOBUILD_MAP_S384, project_mission-tokenization-funding SOURCE: Commander dictation S426 — \"onboarding funnel for selling on araya os, has to be easy like a shopping cart.\"", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-settings-menu-upgrades", "file": "WO-settings-menu-upgrades.md", "title": "WO-settings-menu-upgrades — line up the settings menu (Commander highlighted it)", "what": "WO-settings-menu-upgrades — line up the settings menu (Commander highlighted it)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-shirts-store-revive", "file": "WO-shirts-store-revive.md", "title": "WO — Shirts Store Revive (fastest money: product exists, store is broken)", "what": "WO — Shirts Store Revive (fastest money: product exists, store is broken)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-sign-bug-attachment-display", "file": "WO-sign-bug-attachment-display.md", "title": "WO-sign-bug-attachment-display — Render bug screenshots via signed URLs (bucket is now private)", "what": "WO-sign-bug-attachment-display — Render bug screenshots via signed URLs (bucket is now private)", "why": "S425 security closed the world-readable bug-attachments bucket (flipped private + upload returns a 7-day signed URL). But OLD bug rows store /object/public/bug-attachments/ URLs that now 404, and the redaction path scrubs them for non-Commander. The Commander's board no longer renders historical screenshots until they're re-signed on read. ENABLES: bug triage keeps working with screenshots, with zero world-readable exposure. DO: In tasks-api handleList (the isCommander branch), detect any /object/(public/)?bug-attachments/ or /object/(public/)?vault/ URL in a row's description/fields, extract , mint a short-lived signed URL (POST /storage/v1/object/sign//), and replace it. Apply the same on the bug-detail view if it reads elsewhere. Keep non-Commander scrubbed (no leak).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-signal-forge-music-define", "file": "WO-signal-forge-music-define.md", "title": "WO-signal-forge-music-define — DEFINE: Signal Forge (music)", "what": "WO-signal-forge-music-define — DEFINE: Signal Forge (music)", "why": "North-Star chunk: Signal Forge (music). A fun music-making area: people make songs, bring them back to their Command, and attach them to their vault projects. Lay out the Signal Forge blueprints. ENABLES: completing this turns 'Signal Forge (music)' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/signal-forge-music.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-signal-forge-music", "file": "WO-signal-forge-music.md", "title": "WO-signal-forge-music — make the Signal Forge a place people MAKE MUSIC (blue/741Hz — /signal.html)", "what": "Signal Forge (blue, 741Hz) becomes a music-making hub — people generate/compose music there. REUSE what exists: widget-music.js, the music-generation-pipeline (ElevenLabs, songs-table + player), WO-magical-music-dashboard. ADD a music-gen API tie-in (Suno/ElevenLabs/similar — market-grep first) so a visitor types a vibe → gets a track. Ability-first: it DOES (makes music), not just displays.", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-signup-password-not-persisted", "file": "WO-signup-password-not-persisted.md", "title": "WO — Signup password doesn't authenticate later (auth-door bug #3)", "what": "WO — Signup password doesn't authenticate later (auth-door bug #3)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-slice3b-relink-docs-conversations", "file": "WO-slice3b-relink-docs-conversations.md", "title": "WO-slice3b-relink-docs-conversations — resolver-then-relink for documents/conversations/chat", "what": "WO-slice3b-relink-docs-conversations — resolver-then-relink for documents/conversations/chat", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-speaking-tour-onboarding-define", "file": "WO-speaking-tour-onboarding-define.md", "title": "WO-speaking-tour-onboarding-define — DEFINE: Speaking Tour & Onboarding", "what": "WO-speaking-tour-onboarding-define — DEFINE: Speaking Tour & Onboarding", "why": "North-Star chunk: Speaking Tour & Onboarding. Commander travels — podcasts, YouTube, meeting groups, demoing ARAYA. Needs cards, shirts, a printed itinerary of what he speaks about, and a full onboarding flow of what he shows. ENABLES: completing this turns 'Speaking Tour & Onboarding' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/speaking-tour-onboarding.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-state-adopt-setup-gate", "file": "WO-state-adopt-setup-gate.md", "title": "WO-state-adopt-setup-gate — move the onboarding flag off localStorage onto the state spine", "what": "WO-state-adopt-setup-gate — move the onboarding flag off localStorage onto the state spine", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-store-pattern-clone", "file": "WO-store-pattern-clone.md", "title": "WO-store-pattern-clone — ONE storefront engine, three tenants (Commander · Tiger · Johnny)", "what": "WO-store-pattern-clone — ONE storefront engine, three tenants (Commander · Tiger · Johnny)", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-succession-cockpit-future-blueprint", "file": "WO-succession-cockpit-future-blueprint.md", "title": "WO-succession-cockpit-future-blueprint — the \"throw the laptop away\" round: run without Commander + boot the future-story from all the data", "what": "WO-succession-cockpit-future-blueprint — the \"throw the laptop away\" round: run without Commander + boot the future-story from all the data", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-t11-pilot-closer-loop", "file": "WO-t11-pilot-closer-loop.md", "title": "WO-t11-pilot-closer-loop — 5-card pilot: prove the CLOSER loop, with pulse", "what": "WO-t11-pilot-closer-loop — 5-card pilot: prove the CLOSER loop, with pulse", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-talking-stuffed-animals-kit", "file": "WO-talking-stuffed-animals-kit.md", "title": "Pi Zero → Bluetooth → stuffed animal that talks (Amelia's Explorer Kit) STATUS: open LANE: SOMEDAY-BUT-LIVE", "what": "Pi Zero → Bluetooth → stuffed animal that talks (Amelia's Explorer Kit) STATUS: open LANE: SOMEDAY-BUT-LIVE", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "SOMEDAY-BUT-LIVE", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-the-device-store-gadgets-define", "file": "WO-the-device-store-gadgets-define.md", "title": "WO-the-device-store-gadgets-define — DEFINE: The Device Store (gadgets)", "what": "WO-the-device-store-gadgets-define — DEFINE: The Device Store (gadgets)", "why": "North-Star chunk: The Device Store (gadgets). Collect every builder device in one store — cyber decks, handhelds. Decide: become a wholesale provider for everyone, and/or make our own. Vendors give devices to test free in exch ENABLES: completing this turns 'The Device Store (gadgets)' from a dream into a buildable spec that spawns its build WOs — that is what it allows. DO: Research this chunk and write its spec FILE with these sections filled: '## WHAT' (what gets built), '## WHY' (who it's for), '## USERS', '## WIDGETS', '## DONE-WHEN' (2-3 deterministic checks), '## FIRST-ELEMENT' (the next pipeline WO to spawn). Write it to DNA/VISION_SPECS/the-device-store-gadgets.md. Do not build anything yet — just define it.", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-tier-naming-office-manager-to-operation", "file": "WO-tier-naming-office-manager-to-operation.md", "title": "align L3 backend name to \"The Operation\" STATUS: open LANE: NEXT", "what": "align L3 backend name to \"The Operation\" STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tiger-tax-liens-araya-memory", "file": "WO-tiger-tax-liens-araya-memory.md", "title": "WO-tiger-tax-liens-araya-memory: (PARKED) — do NOT ingest Tiger's software; his lien docs are just files", "what": "WO-tiger-tax-liens-araya-memory: (PARKED) — do NOT ingest Tiger's software; his lien docs are just files", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-trademark-preble-painting-serial", "file": "WO-trademark-preble-painting-serial.md", "title": "PREBLE PAINTING — find the serial number (5th mark, classes 009/037/042) STATUS: open LANE: NEXT", "what": "PREBLE PAINTING — find the serial number (5th mark, classes 009/037/042) STATUS: open LANE: NEXT", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "B3 Compliance Master (Trademark", "priority": "P2", "tier": "A", "transport": "local", "cloud_ready": false }, { "id": "WO-trello-audience-gated-wo-board", "file": "WO-trello-audience-gated-wo-board.md", "title": "WO-trello-audience-gated-wo-board — Wrangle ALL todo/kanban/WO surfaces into ONE Trello/Kanban (one store · one board · N pivots)", "what": "WO-trello-audience-gated-wo-board — Wrangle ALL todo/kanban/WO surfaces into ONE Trello/Kanban (one store · one board · N pivots)", "why": "Task tracking is fragmented across ~2 data stores + 6 widgets + a page + a dozen TODO files: dev_board_tasks (SQL via tasks-api) backs dev-board.html; WORK_ORDERS_BOARD.json (generated from WO .md files) backs widget-workdesk/widget-wo-board; plus widget-board, widget-tasks2, widget-todos, widget-caseboard and MASTER_TODO/TODO/COMMANDER_TODO/etc. The prior-art study BOARD_UX_PRIOR_ART.md (S395) already set the law — \"ONE store, ONE widget, N pivots; never fork the board per audience\" — it just hasn't been executed. This card executes it: unify the stores, make ONE board with group-by pivots (list/status/who) and an audience gate, and retire the rest. DO: Converge the two stores into one feed, extend widget-workdesk into the single Trello/Kanban with a group-by pivot + audience gate (reuse the S426 access_level ladder), and turn every other board surface into a view/redirect. See RING 3.", "where": "Build INTO the ONE shell (widget-workdesk in pulse); reuse todo-claims-api for claim/complete and Auth.getAccessLevel()/meetsAccess() from the S426 scaffold. No new board, no new store.", "who": "COMMANDER-authored; the board is multi-audience by construction (public columns public; dev/commander columns gated). Unclaimed. SPAWN: store-convergence card (reconcile dev_board_tasks ↔ WORK_ORDERS_BOARD.json), drag-between-columns (= field mutation), retire-duplicate-widgets card, per-list share links. RELATED: BOARD_UX_PRIOR_ART.md, ONE_INTERFACE_MASTER_PLAN_S369.md, project_permission-ladder, project_rolling-todo-system, project_one-cockpit-confluence, project_multiplayer-agent-cockpit, WO-seller-onboarding-cart-funnel, WO-opensource-electrical-devices-marketplace, WO-guardian-forge-opensource-tools, WO-health-detox-frequency-tek-marketplace SOURCE: Commander dictation S426 — \"the WO board needs to be like Trello, different columns viewable to different audiences, ~10 WO lists... we need to wrangle in all the todo/kanban/WO system — it can all be turned into a kanban/trello situation.\" (Existing kanban acknowledged: dev-board.html + widget-workdesk.)", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-trinity-dev-widget", "file": "WO-trinity-dev-widget.md", "title": "WO-trinity-dev-widget — In-shell Trinity widget for developers (project start/finish rail)", "what": "ONE widget inside the Pulse shell (ONE-Shell law — no new page, no new surface) that puts the Trinity (C1 Mechanic · C2 Architect · C3 Oracle) in front of a developer at the two moments it matters: - PROJECT START: cascade-style forced planning — the trinity reads the project brief and returns build/design/foresee angles before code is written. - PROJECT END: close-out — verify/receipts/debrief prompts before the PR/hand-off.", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-tune-file-add-ux", "file": "WO-tune-file-add-ux.md", "title": "WO — Tune the File-Add UX (study real file systems, add 5 missing traits)", "what": "WO — Tune the File-Add UX (study real file systems, add 5 missing traits)", "why": "", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-usage-telemetry-clobber", "file": "WO-usage-telemetry-clobber.md", "title": "WO-usage-telemetry-clobber — nightly usage_7d stamps get clobbered by stale-base registry commits (systemic)", "what": "WO-usage-telemetry-clobber — nightly usage_7d stamps get clobbered by stale-base registry commits (systemic)", "why": "Wave-3 comb (S442) C5-telemetry found the SAME root on 8 widgets: PULSE_WIDGET_REGISTRY usage_7d is stale/missing. 19/51 widgets have NO usage_7d at all; the 32 that do are frozen at usage_asof=2026-08-07, while the nightly rollup's own receipt is fresh (usage_latest.json, Aug 15, e.g. calls=8, contacts=13). Real usage lives in analytics_events and the rollup computes it correctly — but registry commits from a STALE BASE overwrite the local-only rollup stamps (USAGE_ROLLUP.py:112-136 stamps working-tree only; the next registry rewrite clobbers it). = the \"gauge mismeasures, fleet is fine\" pattern (project_custom-cockpits-engine). Signal captured then lost at the registry. Every widget's C5/D3 grade is capped at C until this is fixed. DO: - Decide the durable path: either (a) rollup writes usage_7d to a SEPARATE published data file (my/appdash/usage.json) that the gauge reads, NOT into the hand-edited registry (stop the clobber by separating machine-stamped telemetry from hand-curated rows); or (b) rollup commits its own stamps on a schedule and registry edits rebase onto them. - Prefer (a): telemetry is machine data, the registry is a curated catalog — they should not share a file that two writers fight over. Pairs with the WIDGET_LEDGER gauge-mismeasure note. - Backfill the 19 missing widgets once the durable path exists.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-vault-ungate-previewer", "file": "WO-vault-ungate-previewer.md", "title": "WO-vault-ungate-previewer — the on-interface vault previewer works for real users, not just Commander", "what": "WO-vault-ungate-previewer — the on-interface vault previewer works for real users, not just Commander", "why": "widget-canvas (the vault \"Work Area\" / document-preview surface on the pulse cockpit) reads `/.netlify/functions/commander-vault-feed?action=list`, which returns 401 to every non-Commander (commander-vault-feed.mjs guards Commander-only). So a seated builder who logs into the cockpit sees an EMPTY vault + no preview. Meanwhile `vault-api.mjs ?action=list` already lists vault_items scoped to the caller's verified identifiers (email AND uuid) — multi-user and identity-safe. Point the widget at vault-api so the vault works for everyone. This is the #1 vault fix (VAULT_DASHBOARD_FINAL_DESIGN_S426 §4). DO: In components/widgets/widget-canvas.js, change the list feed source from `/.netlify/functions/commander-vault-feed?action=list` to `/.netlify/functions/vault-api?action=list` (keep the `Authorization: Bearer` JWT header). vault-api returns `{ items: [...] }` (rows from vault_items: title, file_url, mime_type, created_at, room, tags) — map those to the card's existing render fields; if commander-vault-feed used `documents`, adapt the field names. Do NOT modify commander-vault-feed.mjs or vault-api.mjs.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-video-in-main-chat", "file": "WO-video-in-main-chat.md", "title": "WO-video-in-main-chat — LiveKit video calls INSIDE Main Chat rooms", "what": "WO-video-in-main-chat — LiveKit video calls INSIDE Main Chat rooms", "why": "PR #1096 (S424, closed S453 by merge-captain triage) built a standalone /video-room.html with a ONE-GATE LiveKit token server — solid code, wrong door: the S436 one-chat consolidation law says any new room/call surface must be born INSIDE Main Chat, never as a new page. LiveKit never landed anywhere else, so the capability is still wanted. SALVAGE: closed PR #1096 (branch opencode-122-livekit-room preserved) — reuse `livekit-token.mjs` (token server with access_level>=7 host controls) nearly as-is; the room UI must be rebuilt as a Main Chat room feature, not ported.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P3", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-view-01-gate", "file": "WO-view-01-gate.md", "title": "WO-view-01-gate — Front Door + Identity as ONE entry view (Gate)", "what": "WO-view-01-gate — Front Door + Identity as ONE entry view (Gate)", "why": "One of the locked 6 views. Front Door (explain+enter) and Identity (authenticate+permissions) are one funnel; keep them a single Gate lens. Provider login (GitHub/Google) already exists — don't rebuild. DO: Screenshot current -> VIEW_SLOTS/current/01-gate.png. Clean SaaS landing -> Enter/Log In -> Forge Passport auth -> lands in Home (Pulse). Blueprint-card: every button->destination, data=profiles+access_level. Borrow SaaS-landing + Supabase-Auth patterns. Re-shoot into slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-02-home", "file": "WO-view-02-home.md", "title": "WO-view-02-home — Home / \"what needs attention\" (Pulse V2)", "what": "WO-view-02-home — Home / \"what needs attention\" (Pulse V2)", "why": "One of the locked 6 views. The \"what the hell is happening right now\" screen: my work / team / attention / recent. It is the OS-desktop lens over the one task graph, NOT another board. DO: Screenshot current -> VIEW_SLOTS/current/02-home.png. Blueprint-card: MY WORK (assigned/awaiting/ blocked) · TEAM · ATTENTION (build/PR/blocked) · RECENT activity — all read from dev_board_tasks + spine. Every tile deep-links to the task. Upgrade to BUILDER_STANDARD. Re-shoot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-03-chat-redo", "file": "WO-view-03-chat-redo.md", "title": "WO-view-03-chat-redo — Guild Home / MAIN CHAT is real bad, full redo (P0)", "what": "WO-view-03-chat-redo — Guild Home / MAIN CHAT is real bad, full redo (P0)", "why": "Commander sent Toasted a link; thumbnail says \"Case Builder\", opens a public view where anyone can watch the conversation, and the chat is \"terrible looking / demented / real bad\". This is view 03 (Guild Home) — the lobby + first impression. It shames the whole guild. Redo the whole thing. DO: Screenshot current (proof of before). Redesign the chat surface to Discord/Slack quality: clean room rail (permission-based rooms: Build Guild/Case Builder/Builder Revolution), readable message thread, composer, presence. Fix the shareable public-conversation view (the \"anybody can watch\" link) so it looks intentional, not broken. Match BUILDER_STANDARD. Borrow proven room/thread UX, don't invent.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P0", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-04-command-center", "file": "WO-view-04-command-center.md", "title": "WO-view-04-command-center — upgrade the Command Center view to its blueprint-card", "what": "WO-view-04-command-center — upgrade the Command Center view to its blueprint-card", "why": "One of the 7 locked Build Guild views. Must match its blueprint-card and borrow the proven pattern (Trello + Linear) instead of inventing navigation. It is a LENS on the one task/object graph, not a separate app. DO: Screenshot current -> VIEW_SLOTS/current/04-command-center.png. the WO Kanban; columns Backlog/Ready/Active/Review/QA/Done + Blocked state; card=the task; Grab -> Workbench. Write/confirm its blueprint-card (purpose·model·every button->destination·data object). Upgrade to BUILDER_STANDARD. Re-shoot into the slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-05-workbench", "file": "WO-view-05-workbench.md", "title": "WO-view-05-workbench — upgrade the Workbench view to its blueprint-card", "what": "WO-view-05-workbench — upgrade the Workbench view to its blueprint-card", "why": "One of the 7 locked Build Guild views. Must match its blueprint-card and borrow the proven pattern (GitHub + IDE/Codespaces) instead of inventing navigation. It is a LENS on the one task/object graph, not a separate app. DO: Screenshot current -> VIEW_SLOTS/current/05-workbench.png. THE GAP: per-task workspace (requirements+files+code+contextual ARAYA+chat); Submit Review -> view 06; this is the one real build. Write/confirm its blueprint-card (purpose·model·every button->destination·data object). Upgrade to BUILDER_STANDARD. Re-shoot into the slot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-view-06-knowledge-ship", "file": "WO-view-06-knowledge-ship.md", "title": "WO-view-06-knowledge-ship — Knowledge / Ship (releases + docs + deploy)", "what": "WO-view-06-knowledge-ship — Knowledge / Ship (releases + docs + deploy)", "why": "One of the locked 6 views. Releases, documentation, tutorials, completed projects; Ship = deploy. DO: Screenshot current -> VIEW_SLOTS/current/06-knowledge-ship.png. Blueprint-card: releases·docs· tutorials·build-logs·completed-projects; Ship button = bash DEPLOY.sh (NEVER bare netlify). Borrow Notion + GitHub Releases. Re-shoot.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-voice-action-tools", "file": "WO-voice-action-tools.md", "title": "wire ARAYA's action-tools into the VOICE path (run the business by talking to the phone) STATUS: open LANE: FRONTIER", "what": "wire ARAYA's action-tools into the VOICE path (run the business by talking to the phone) STATUS: open LANE: FRONTIER", "why": "", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "FRONTIER", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-voice-text-fallback", "file": "WO-voice-text-fallback.md", "title": "WO-voice-text-fallback — Add a text-input fallback to araya-voice.html (POSTs to the real araya-chat function)", "what": "local model edit via aider", "why": "Voice-only excludes anyone who can't/won't talk (Bill Varney lane). S420 a free unit tried this and hallucinated a fake /send-text endpoint; this card is self-contained with the REAL code. DO: In araya-voice.html make exactly two insertions, changing nothing else.", "where": "aider edited: araya-voice.html (working tree, uncommitted — review/promote)", "who": "aider-local", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "A", "transport": "", "cloud_ready": false }, { "id": "WO-widget-contract-fleet-sweep", "file": "WO-widget-contract-fleet-sweep.md", "title": "WO-widget-contract-fleet-sweep — full-fleet widget-contract check (missing mount() = phantom orphans)", "what": "WO-widget-contract-fleet-sweep — full-fleet widget-contract check (missing mount() = phantom orphans)", "why": "S442 Phase-1 fixer (PR #1220) found widget-vault.js was missing its required `mount()` — documented in the file's contract but never implemented — so the shell could never mount it. THIS is why the comb flagged vault as a never-loading orphan while the registry stamped it LIVE. The Widget Contract Lint only runs on CHANGED files, so an unknown number of unmodified widgets have the same silent missing-mount (or other contract) gap — each one a widget the registry calls LIVE that no shell can actually render. The ledger already lists 5 orphans (widget-green-projects/maps/news-reader/vault/voice); vault's root was a missing mount, so the others deserve the same check. DO: - Run the Widget Contract Lint over the whole components/widgets/ fleet once; list every widget missing a required contract method (mount/renderCard/renderExpanded/unmount) or exports. - For each real widget (not a to-be-retired orphan), add the minimal honest method (mirror a sibling, as vault's mount delegated to renderExpanded). For genuine orphans, hand to WO-widget-dedupe. - Pairs with WO-registry-verdict-integrity: a widget missing mount() must NOT be stamped verdict:LIVE.", "where": "", "who": "", "status": "done", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P1", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-dedupe-calls-comms-cluster", "file": "WO-widget-dedupe-calls-comms-cluster.md", "title": "WO-widget-dedupe-calls-comms-cluster — one calls/comms surface, one registry row (de-dupe)", "what": "WO-widget-dedupe-calls-comms-cluster — one calls/comms surface, one registry row (de-dupe)", "why": "Wave-3 comb (S442) C2-split found on `calls`: 1. RIVAL CANONICAL CLAIM — components/widgets/widget-news-reader.js declares it \"Replaces widget-calls.js + widget-messages.js + widget-email.js + widget-dm.js + widget-comms.js\" and calls itself \"the ONE canonical comms surface\" (S415) — but it is an ORPHAN: mounted by zero HTML, absent from PULSE_WIDGET_REGISTRY, only in WIDGET_LEDGER.csv row 37 loaded=False. Two files each claim to be THE calls surface; widget-calls.js is the one actually shipped. 2. LIVE ORG-CHART CONFLICT — DNA/ORG_CHART.json carries TWO name_collision rows for one object: node 474 'widget-calls' (kind=widget, RoR=WIDGET_LEDGER.csv) + node 558 'M-ec5301' \"Calls\" (kind=module, RoR=MODULE_REGISTRY.json, path pulse.html?open=calls). Same widget, two IDs, two registries of record. Confirmed live on prod. DO: - Decide canonical: widget-calls.js is shipped → either DELETE the orphan widget-news-reader.js (reversible; it loads nowhere) or downgrade its header claim so it stops claiming to be THE comms surface. Same for the other 4 it claims to replace (messages/email/dm/comms) — verify each is or isn't actually superseded before touching. - Collapse the org-chart double-track: one object = one row. Pick the RoR (widget → WIDGET_LEDGER or the unified MASTER_REGISTRY) and make the module row (M-ec5301) an alias/pointer, not a second object. This is the exact \"165 conflicts\" de-dupe the org chart was built to drive. - Re-run the org-chart generator; the two name_collision flags for calls must clear.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-widget-split-program", "file": "WO-widget-split-program.md", "title": "WO-widget-split-program — The split program — 22 oversized widgets down to crew size, one per card", "what": "WO-widget-split-program — The split program — 22 oversized widgets down to crew size, one per card", "why": "Ledger S420b: 22 widgets exceed the 400L crew ceiling (worst: planner 942, leads2 938, canvas 928). Every split converts a manager-only file into crew territory — the compounding unlock for the North Star. ENABLES: once done, builders + users get widget split program working in-shell — it unlocks that capability on the board (what completing it allows). DO: Manager-lane program: per widget, extract views/data helpers into widget-X-views.js keeping the contract file under 400L; one widget per session max; regenerate the ledger after each as the receipt; start with widget-comms (843L, comms is a live business lane).", "where": "", "who": "", "status": "blocked", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-widget-wiring-view", "file": "WO-widget-wiring-view.md", "title": "WO-widget-wiring-view — read-only wiring-graph EXPLAIN view from the registries", "what": "WO-widget-wiring-view — read-only wiring-graph EXPLAIN view from the registries", "why": "PR #941 (S417, closed S453 by merge-captain triage) built site/widget-flow.html — an n8n-style visual canvas — but the branch was 36 files of tangled S417 sprawl around that one deliverable, and a standalone editor page violates ONE-shell + the registries are now the single source of truth (WIDGET_FACTORY.md). The small, still-wanted kernel is the read-only EXPLAIN view generated from the registries. SALVAGE: branch opencode-56/widget-flow-editor preserved — site/widget-flow.html's render code is reference-only; rebuild as a view, generated, read-only.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "", "transport": "", "cloud_ready": false }, { "id": "WO-woboard-kill-merge", "file": "WO-woboard-kill-merge.md", "title": "WO-woboard-kill-merge — retire woboard into workdesk (duplicate, no sellable tier)", "what": "WO-woboard-kill-merge — retire woboard into workdesk (duplicate, no sellable tier)", "why": "Wave-3 batch-3 comb + critic — woboard scored HEALTH 68 (every dimension C/D) and was being combed as a fixable widget, BUT its own C6-wealth lens says it is on NO sellable tier and it duplicates the work-order/board surface that workdesk (id 'workdesk', S426) already owns as the superset (BOARD view = unified board-feed). \"BOARD-CLUSTER TRIPLICATION\" — three script-loaded widgets cover the same board. Fixing woboard is wasted effort; the move is to retire it, not repair it. STOP combing it as fixable. DO: confirm workdesk covers woboard's function; retire woboard (unregister from shell, mark orphan/retired in registry, or redirect its door to workdesk); fold any unique woboard capability into workdesk first. Pairs with the board-cluster de-dupe (workdesk C2-split) + WO-widget-dedupe.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "", "next": "", "routed": "UNROUTED", "project": "", "priority": "P2", "tier": "C", "transport": "", "cloud_ready": false }, { "id": "WO-xp-award-hardening-round2", "file": "WO-xp-award-hardening-round2.md", "title": "the remaining xp-award security debts STATUS: open LANE: NEXT", "what": "the remaining xp-award security debts STATUS: open LANE: NEXT", "why": "#1234 sealed the unlimited-mint hole and #1239 caps repeat-farming, but adversarial review (C9, 2 rounds) filed four residual debts. They're not blockers for the loop going live, but they should land before XP gates anything of value (WO-xp-room-unlock depends on the first one).", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false }, { "id": "WO-xp-room-unlock", "file": "WO-xp-room-unlock.md", "title": "crossing an XP floor unlocks a room (the promotion mechanic) STATUS: open LANE: NEXT", "what": "crossing an XP floor unlocks a room (the promotion mechanic) STATUS: open LANE: NEXT", "why": "The reward loop pays XP and now shows it (HUD, #1238), but XP doesn't yet UNLOCK anything — \"cross a floor → a room opens\" is the payoff that makes leveling matter. Investigated S449: rooms (rooms-api.mjs) are MEMBERSHIP/invite-based, NOT gated by xp or access_level. So this is net-new, and HOW it's wired matters for security.", "where": "", "who": "", "status": "open", "claimer": "", "lane_raw": "NEXT", "next": "", "routed": "UNROUTED", "project": "Build Guild", "priority": "P2", "tier": "B", "transport": "", "cloud_ready": false } ] }, "cloud_queue": [ { "id": "BUG-205", "title": "araya-chat — cannot expand past conversations", "tier": "A", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "Routing logic omits conversation ID parameter on selection" }, { "id": "BUG-207", "title": "team-comms.html mobile — leftover purple-button animation", "tier": "A", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "Orphaned animation code; verifiable by caller grep" }, { "id": "WO-dev-one-door-prototype", "title": "ONE door — sign in, see the work, claim a WO, ARAYA builds it with you, vault stores it STATUS: open LANE: NOW", "tier": "B", "transport": "outside-ok", "priority": "P1", "status": "open", "claimer": "", "prove": "harness-verify + visual-verify" }, { "id": "WO-devcenter-reward-loop", "title": "Wire done → review → XP actually pays out (+ persist WO claim) STATUS: open LANE: NOW", "tier": "B", "transport": "outside-ok", "priority": "P1", "status": "open", "claimer": "", "prove": "harness-verify" }, { "id": "WO-file-indexing-ingest", "title": "EVERY file gets a permanent index number that never changes — find it anywhere it moves STATUS: open LANE: NOW", "tier": "B", "transport": "outside-ok", "priority": "P1", "status": "open", "claimer": "", "prove": "harness-verify" }, { "id": "WO-youtube-transcription-processor", "title": "YouTube transcription processor — chunk startup videos into a blueprint/handbook of patterns + guardrails STATUS: open LANE: NOW", "tier": "B", "transport": "outside-ok", "priority": "P1", "status": "open", "claimer": "", "prove": "harness-verify" }, { "id": "BUG-201", "title": "araya-chat.html mobile — chat text box overlapped by lower menu", "tier": "B", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "mobile browser viewport verification" }, { "id": "BUG-202", "title": "araya-chat.html mobile — bottom nav buttons unresponsive in chat", "tier": "B", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "Mobile browser/device to verify touch responsiveness" }, { "id": "BUG-203", "title": "araya-chat.html mobile — top buttons running off the screen", "tier": "B", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "mobile viewport verification (flag runtime-unverified per DONE)" }, { "id": "BUG-208", "title": "araya-chat.html — voice-mode options cut off / unscrollable", "tier": "B", "transport": "outside-ok", "priority": "P2", "status": "open", "claimer": "", "prove": "browser/device to verify scroll behavior" } ], "conveyor": { "generated": "2026-08-28T08:20:01.190942", "open": 665, "done": 216, "partial": 2, "delta_7d": 10, "growth_streak_days": 4, "days_tracked": 49 }, "goal": { "quarter_aim": [ "2. MONEY: first real sale plus the reseller rail live (Omar + receptionist line) — revenue > $0", "3. MACHINE: the planner/wrap/maintenance loops all green unattended for 14 straight days —" ] }, "seats": [ { "seat": "CP2-1", "last_ts": "2026-07-31T23:10:07", "last_type": "done", "last_wo": "WO-window-A-functions-araya", "age_min": 40345, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP2-2", "last_ts": "2026-08-01T06:10:52", "last_type": "done", "last_wo": "WO-refresh-ryan-onboarding-doc", "age_min": 39924, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP2-3", "last_ts": "2026-07-31T22:52:58", "last_type": "progress", "last_wo": "WO-github-failure-feedback", "age_min": 40362, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3", "last_ts": "2026-08-25T12:10:50", "last_type": "debrief", "last_wo": "", "age_min": 5004, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-S415", "last_ts": "2026-08-06T15:29:02", "last_type": "debrief", "last_wo": "", "age_min": 32166, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-S423", "last_ts": "2026-08-08T10:14:40", "last_type": "debrief", "last_wo": "", "age_min": 29601, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-S434", "last_ts": "2026-08-11T23:51:13", "last_type": "debrief", "last_wo": "", "age_min": 24464, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-S437", "last_ts": "2026-08-13T18:21:39", "last_type": "debrief", "last_wo": "", "age_min": 21914, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-araya", "last_ts": "2026-08-26T20:44:50", "last_type": "debrief", "last_wo": "", "age_min": 3050, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-claude", "last_ts": "2026-08-07T21:20:01", "last_type": "debrief", "last_wo": "", "age_min": 30375, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-legal", "last_ts": "2026-08-28T15:07:20", "last_type": "debrief", "last_wo": "", "age_min": 508, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-main", "last_ts": "2026-08-26T23:59:00", "last_type": "debrief", "last_wo": "S462-wo-organizing-wave", "age_min": 2856, "live": false, "cards": [], "park_count": 0 }, { "seat": "CP3-model-lane", "last_ts": "2026-08-06T13:57:50", "last_type": "blocked", "last_wo": "", "age_min": 32257, "live": false, "cards": [], "park_count": 0 }, { "seat": "Fable5", "last_ts": "2026-08-16T17:12:30", "last_type": "debrief", "last_wo": "", "age_min": 17663, "live": false, "cards": [], "park_count": 0 }, { "seat": "S403c", "last_ts": "2026-08-04T19:39:41", "last_type": "debrief", "last_wo": "", "age_min": 34796, "live": false, "cards": [], "park_count": 0 }, { "seat": "S408-fable-bg", "last_ts": "2026-08-04T20:58:16", "last_type": "debrief", "last_wo": "", "age_min": 34717, "live": false, "cards": [], "park_count": 0 }, { "seat": "S435-chat", "last_ts": "2026-08-12T01:31:01", "last_type": "debrief", "last_wo": "", "age_min": 24364, "live": false, "cards": [], "park_count": 0 }, { "seat": "S438-drain", "last_ts": "2026-08-14T13:05:04", "last_type": "debrief", "last_wo": "", "age_min": 20790, "live": false, "cards": [], "park_count": 0 }, { "seat": "S468-widgets", "last_ts": "2026-08-28T18:10:18", "last_type": "debrief", "last_wo": "", "age_min": 325, "live": false, "cards": [], "park_count": 0 }, { "seat": "T1", "last_ts": "2026-08-26T11:53:28", "last_type": "debrief", "last_wo": "", "age_min": 3582, "live": false, "cards": [], "park_count": 0 }, { "seat": "T1-opus", "last_ts": "2026-07-31T17:34:05", "last_type": "progress", "last_wo": "WO-opencode-grade-proof", "age_min": 40681, "live": false, "cards": [], "park_count": 0 }, { "seat": "T1-strapping", "last_ts": "2026-07-31T17:04:11", "last_type": "done", "last_wo": "WO-strapping-agent-door", "age_min": 40711, "live": false, "cards": [], "park_count": 0 }, { "seat": "T2", "last_ts": "2026-07-31T14:32:44", "last_type": "debrief", "last_wo": "", "age_min": 40863, "live": false, "cards": [], "park_count": 0 }, { "seat": "T3", "last_ts": "2026-07-30T23:56:22", "last_type": "done", "last_wo": "", "age_min": 41739, "live": false, "cards": [], "park_count": 0 }, { "seat": "T453", "last_ts": "2026-08-22T00:17:15", "last_type": "debrief", "last_wo": "", "age_min": 10038, "live": false, "cards": [], "park_count": 0 }, { "seat": "WO-strapping-selftest-fleet", "last_ts": "2026-07-31T15:36:51", "last_type": "done", "last_wo": "WO-strapping-selftest", "age_min": 40798, "live": false, "cards": [], "park_count": 0 }, { "seat": "WO-strapping-selftest-fleet-0", "last_ts": "2026-07-31T15:36:51", "last_type": "progress", "last_wo": "WO-strapping-selftest", "age_min": 40798, "live": false, "cards": [], "park_count": 0 }, { "seat": "WO-strapping-selftest-fleet-1", "last_ts": "2026-07-31T15:36:50", "last_type": "progress", "last_wo": "WO-strapping-selftest", "age_min": 40798, "live": false, "cards": [], "park_count": 0 }, { "seat": "aider-local", "last_ts": "2026-08-28T20:13:54", "last_type": "claim", "last_wo": "WO-mloop-canary", "age_min": 201, "live": false, "cards": [], "park_count": 0 }, { "seat": "big-pickle", "last_ts": "2026-08-11T11:39:56", "last_type": "claim", "last_wo": "WO-developer-direction-page", "age_min": 25195, "live": false, "cards": [], "park_count": 0 }, { "seat": "claude-2", "last_ts": "2026-08-05T19:01:24", "last_type": "debrief", "last_wo": "", "age_min": 33394, "live": false, "cards": [], "park_count": 0 }, { "seat": "claude-cp3", "last_ts": "2026-08-11T13:32:29", "last_type": "debrief", "last_wo": "WO-hud-comms-music+BG-5-identity-bridge", "age_min": 25083, "live": false, "cards": [], "park_count": 0 }, { "seat": "conveyor-fleet", "last_ts": "2026-07-31T15:19:01", "last_type": "done", "last_wo": "WO-conveyor-triage-drain", "age_min": 40816, "live": false, "cards": [], "park_count": 0 }, { "seat": "hermes-test", "last_ts": "2026-07-31T18:09:32", "last_type": "done", "last_wo": "WO-mcp-selftest", "age_min": 40646, "live": false, "cards": [], "park_count": 0 }, { "seat": "k2-1", "last_ts": "2026-08-05T18:59:28", "last_type": "done", "last_wo": "all", "age_min": 33396, "live": false, "cards": [], "park_count": 0 }, { "seat": "k3-a", "last_ts": "2026-08-05T17:05:12", "last_type": "claim", "last_wo": "WO-entry-point-presentability-audit", "age_min": 33510, "live": false, "cards": [], "park_count": 0 }, { "seat": "k3-b", "last_ts": "2026-08-05T17:01:10", "last_type": "debrief", "last_wo": "WO-comms-unity-group-chat", "age_min": 33514, "live": false, "cards": [], "park_count": 0 }, { "seat": "k3-c", "last_ts": "2026-08-05T17:03:33", "last_type": "debrief", "last_wo": "WO-component-library-index", "age_min": 33512, "live": false, "cards": [], "park_count": 0 }, { "seat": "k3-test", "last_ts": "2026-08-05T16:23:16", "last_type": "debrief", "last_wo": "WO-araya-v2-pulse-landing-chat", "age_min": 33552, "live": false, "cards": [], "park_count": 0 }, { "seat": "manager-fable", "last_ts": "2026-08-07T17:32:25", "last_type": "blocked", "last_wo": "WO-accounting-spine-organ", "age_min": 30603, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode", "last_ts": "2026-08-09T00:42:27", "last_type": "claim", "last_wo": "WO-vault-ungate-previewer", "age_min": 28733, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-1", "last_ts": "2026-08-05T18:53:29", "last_type": "debrief", "last_wo": "", "age_min": 33402, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-10", "last_ts": "2026-08-06T00:21:30", "last_type": "debrief", "last_wo": "WO-self-healing-everywhere", "age_min": 33074, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-100", "last_ts": "2026-08-07T19:24:10", "last_type": "claim", "last_wo": "WO-orphan-widgets-decision", "age_min": 30491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-101", "last_ts": "2026-08-07T19:24:08", "last_type": "claim", "last_wo": "WO-contributor-agreement-gate", "age_min": 30491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-102", "last_ts": "2026-08-07T19:34:07", "last_type": "claim", "last_wo": "WO-scoped-contributor-guild", "age_min": 30481, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-103", "last_ts": "2026-08-07T19:44:06", "last_type": "claim", "last_wo": "WO-standards-tombstone-sweep", "age_min": 30471, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-104", "last_ts": "2026-08-07T19:54:09", "last_type": "claim", "last_wo": "WO-action-reaction-tier3", "age_min": 30461, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-105", "last_ts": "2026-08-07T19:44:10", "last_type": "claim", "last_wo": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842", "age_min": 30471, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-106", "last_ts": "2026-08-07T20:36:00", "last_type": "debrief", "last_wo": "WO-supply-lesson-mcp-first-architecture-connect-araya-to-20260806-052842", "age_min": 30419, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-107", "last_ts": "2026-08-07T20:33:56", "last_type": "debrief", "last_wo": "WO-supply-lesson-memory-integration-for-bug-loops-implem-20260806-052842", "age_min": 30421, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-108", "last_ts": "2026-08-07T20:35:56", "last_type": "debrief", "last_wo": "WO-supply-lesson-migrate-araya-to-cloud-vms-stop-running-20260806-052842", "age_min": 30419, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-109", "last_ts": "2026-08-07T20:55:11", "last_type": "debrief", "last_wo": "WO-supply-lesson-self-improving-bug-loops-configure-the-20260806-052842", "age_min": 30400, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-11", "last_ts": "2026-08-06T00:23:52", "last_type": "debrief", "last_wo": "WO-lead-pipeline-v2", "age_min": 33071, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-110", "last_ts": "2026-08-07T21:33:26", "last_type": "claim", "last_wo": "WO-thumb-drive-packout", "age_min": 30362, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-111", "last_ts": "2026-08-07T21:32:45", "last_type": "claim", "last_wo": "WO-supply-lesson-widget-context-injection-each-dashboard-20260806-052842", "age_min": 30363, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-112", "last_ts": "2026-08-07T21:35:06", "last_type": "claim", "last_wo": "WO-vin-stamp-machine", "age_min": 30360, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-113", "last_ts": "2026-08-08T17:45:20", "last_type": "debrief", "last_wo": "WO-l5-template-rings", "age_min": 29150, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-114", "last_ts": "2026-08-08T17:40:13", "last_type": "debrief", "last_wo": "WO-dev-pack", "age_min": 29155, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-115", "last_ts": "2026-08-08T17:39:03", "last_type": "debrief", "last_wo": "WO-hud-skin-wiring", "age_min": 29156, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-116", "last_ts": "2026-08-08T18:25:07", "last_type": "debrief", "last_wo": "WO-audit-widget-projects", "age_min": 29110, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-117", "last_ts": "2026-08-08T18:27:53", "last_type": "debrief", "last_wo": "WO-audit-widget-revenue", "age_min": 29107, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-118", "last_ts": "2026-08-08T18:31:05", "last_type": "debrief", "last_wo": "WO-audit-widget-scorecard", "age_min": 29104, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-119", "last_ts": "2026-08-09T01:19:07", "last_type": "debrief", "last_wo": "WO-blueprint-at-every-dead-end-define", "age_min": 28696, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-12", "last_ts": "2026-08-06T00:51:25", "last_type": "debrief", "last_wo": "WO-lesson-to-wo-generator", "age_min": 33044, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-120", "last_ts": "2026-08-09T01:30:58", "last_type": "debrief", "last_wo": "WO-beta-test-tracking-system", "age_min": 28684, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-121", "last_ts": "2026-08-09T01:12:07", "last_type": "debrief", "last_wo": "WO-automation-empire-update", "age_min": 28703, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-122", "last_ts": "2026-08-09T01:59:57", "last_type": "debrief", "last_wo": "WO-builder-standard-reconcile", "age_min": 28655, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-123", "last_ts": "2026-08-09T02:01:21", "last_type": "claim", "last_wo": "WO-commander-daily-page", "age_min": 28654, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-124", "last_ts": "2026-08-09T02:02:31", "last_type": "claim", "last_wo": "WO-complete-starter-menu-easy-tasks", "age_min": 28653, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-125", "last_ts": "2026-08-09T17:58:54", "last_type": "debrief", "last_wo": "WO-deadend-audit-builder-path", "age_min": 27696, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-126", "last_ts": "2026-08-09T18:02:29", "last_type": "debrief", "last_wo": "WO-define-builder-widget-bundle", "age_min": 27693, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-127", "last_ts": "2026-08-09T17:54:26", "last_type": "debrief", "last_wo": "WO-daily-tightening-comb", "age_min": 27701, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-128", "last_ts": "2026-08-09T18:46:35", "last_type": "debrief", "last_wo": "WO-fill-organ-house--claude-heartbeat", "age_min": 27649, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-129", "last_ts": "2026-08-09T19:15:48", "last_type": "debrief", "last_wo": "WO-every-dead-end-calls-us", "age_min": 27619, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-13", "last_ts": "2026-08-06T00:56:22", "last_type": "debrief", "last_wo": "WO-free-agent-fleet-signup", "age_min": 33039, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-130", "last_ts": "2026-08-09T18:45:51", "last_type": "debrief", "last_wo": "WO-fill-organ-house--claude-board", "age_min": 27649, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-131", "last_ts": "2026-08-09T19:46:43", "last_type": "debrief", "last_wo": "WO-fill-organ-house--claude-state", "age_min": 27589, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-132", "last_ts": "2026-08-09T19:58:14", "last_type": "debrief", "last_wo": "WO-fill-organ-house--claude-state", "age_min": 27577, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-133", "last_ts": "2026-08-09T20:02:44", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-1-0-heartbeat", "age_min": 27573, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-134", "last_ts": "2026-08-09T20:39:13", "last_type": "debrief", "last_wo": "WO-110-resiliency-backup-verify", "age_min": 27536, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-135", "last_ts": "2026-08-09T20:39:12", "last_type": "debrief", "last_wo": "WO-110-compliance-audit-trail", "age_min": 27536, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-136", "last_ts": "2026-08-09T20:40:07", "last_type": "debrief", "last_wo": "WO-110-risk-opsec-scan", "age_min": 27535, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-137", "last_ts": "2026-08-09T20:54:22", "last_type": "debrief", "last_wo": "WO-fill-organ-house--consciousness-gauge", "age_min": 27521, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-138", "last_ts": "2026-08-09T20:54:24", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-11-0-heartbeat", "age_min": 27521, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-139", "last_ts": "2026-08-09T20:54:26", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-12-0-board", "age_min": 27521, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-14", "last_ts": "2026-08-06T00:53:47", "last_type": "debrief", "last_wo": "WO-human-work-router", "age_min": 33041, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-140", "last_ts": "2026-08-09T21:04:26", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-12-0-heartbeat", "age_min": 27511, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-141", "last_ts": "2026-08-09T21:04:28", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-13-0-board", "age_min": 27511, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-142", "last_ts": "2026-08-09T21:04:30", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-13-0-heartbeat", "age_min": 27511, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-143", "last_ts": "2026-08-09T21:14:26", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-3-0-board", "age_min": 27501, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-144", "last_ts": "2026-08-09T21:14:26", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-3-0-heartbeat", "age_min": 27501, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-145", "last_ts": "2026-08-09T21:14:28", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-4-0-board", "age_min": 27501, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-146", "last_ts": "2026-08-09T21:24:25", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-4-0-state", "age_min": 27491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-147", "last_ts": "2026-08-09T21:24:26", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-5-0-board", "age_min": 27491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-148", "last_ts": "2026-08-09T21:24:28", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-7-0-board", "age_min": 27491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-149", "last_ts": "2026-08-09T21:34:24", "last_type": "debrief", "last_wo": "WO-external-dev-mvp-drop-anywhere", "age_min": 27481, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-150", "last_ts": "2026-08-09T21:34:27", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-7-0-state", "age_min": 27481, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-151", "last_ts": "2026-08-09T21:34:27", "last_type": "debrief", "last_wo": "WO-fill-organ-pcf-9-0-board", "age_min": 27481, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-152", "last_ts": "2026-08-09T21:44:25", "last_type": "debrief", "last_wo": "WO-fix-start-widget-reachable", "age_min": 27471, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-153", "last_ts": "2026-08-09T21:44:28", "last_type": "debrief", "last_wo": "WO-fix-start-widget-token-fetch", "age_min": 27471, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-154", "last_ts": "2026-08-09T21:44:29", "last_type": "debrief", "last_wo": "WO-fleet-gauge-honesty-pack", "age_min": 27471, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-155", "last_ts": "2026-08-09T21:54:17", "last_type": "debrief", "last_wo": "WO-fleet-tier3-watcher", "age_min": 27461, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-156", "last_ts": "2026-08-09T21:54:19", "last_type": "debrief", "last_wo": "WO-fractal-benchmarking-harness", "age_min": 27461, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-157", "last_ts": "2026-08-09T21:54:21", "last_type": "debrief", "last_wo": "WO-fractal-dna-rollout", "age_min": 27461, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-158", "last_ts": "2026-08-09T22:04:29", "last_type": "debrief", "last_wo": "WO-framework-state-caretag-schema", "age_min": 27451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-159", "last_ts": "2026-08-09T22:04:31", "last_type": "debrief", "last_wo": "WO-fundraising-business-plan-define", "age_min": 27451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-160", "last_ts": "2026-08-09T22:04:31", "last_type": "debrief", "last_wo": "WO-gap-matrix-framework", "age_min": 27451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-161", "last_ts": "2026-08-09T22:14:23", "last_type": "debrief", "last_wo": "WO-blab-capture-flow", "age_min": 27441, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-162", "last_ts": "2026-08-09T22:14:25", "last_type": "debrief", "last_wo": "WO-boot-canonical-registry", "age_min": 27441, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-163", "last_ts": "2026-08-09T22:14:27", "last_type": "debrief", "last_wo": "WO-github-failure-feedback", "age_min": 27441, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-164", "last_ts": "2026-08-09T22:24:18", "last_type": "debrief", "last_wo": "WO-growth-blueprint-to-work-orders", "age_min": 27431, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-165", "last_ts": "2026-08-09T22:24:21", "last_type": "debrief", "last_wo": "WO-harness-set-num-ctx", "age_min": 27431, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-166", "last_ts": "2026-08-09T22:24:23", "last_type": "debrief", "last_wo": "WO-harness-whole-edit-format", "age_min": 27431, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-167", "last_ts": "2026-08-09T22:34:23", "last_type": "debrief", "last_wo": "WO-html-placement-gate", "age_min": 27421, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-168", "last_ts": "2026-08-09T22:34:25", "last_type": "debrief", "last_wo": "WO-human-on-the-phone-per-product-define", "age_min": 27421, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-169", "last_ts": "2026-08-09T22:34:26", "last_type": "debrief", "last_wo": "WO-idea-intake-router", "age_min": 27421, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-170", "last_ts": "2026-08-09T22:44:18", "last_type": "debrief", "last_wo": "WO-inside-oracle-broker", "age_min": 27411, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-171", "last_ts": "2026-08-09T22:44:20", "last_type": "debrief", "last_wo": "WO-isolate-component-repos", "age_min": 27411, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-172", "last_ts": "2026-08-09T22:44:21", "last_type": "debrief", "last_wo": "WO-item-walkthrough-command", "age_min": 27411, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-173", "last_ts": "2026-08-09T22:54:21", "last_type": "debrief", "last_wo": "WO-living-tree-build-display", "age_min": 27401, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-174", "last_ts": "2026-08-09T22:54:24", "last_type": "debrief", "last_wo": "WO-manager-diff-review-gate", "age_min": 27401, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-175", "last_ts": "2026-08-09T22:54:26", "last_type": "debrief", "last_wo": "WO-mesh-comms-builders-as-nodes-define", "age_min": 27401, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-176", "last_ts": "2026-08-09T23:04:21", "last_type": "debrief", "last_wo": "WO-mission-partner-network-define", "age_min": 27391, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-177", "last_ts": "2026-08-09T23:04:24", "last_type": "debrief", "last_wo": "WO-missions-make-sell-tokenize-define", "age_min": 27391, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-178", "last_ts": "2026-08-09T23:04:25", "last_type": "debrief", "last_wo": "WO-newsreader-demo-fallback", "age_min": 27391, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-179", "last_ts": "2026-08-09T23:14:14", "last_type": "debrief", "last_wo": "WO-node-harness-test-utility", "age_min": 27381, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-18", "last_ts": "2026-08-06T04:45:06", "last_type": "debrief", "last_wo": "WO-permission-tiers-enforced", "age_min": 32810, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-180", "last_ts": "2026-08-09T23:14:16", "last_type": "debrief", "last_wo": "WO-onboard-funnel-router", "age_min": 27381, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-181", "last_ts": "2026-08-09T23:14:19", "last_type": "debrief", "last_wo": "WO-onboarding-tutorial-book", "age_min": 27381, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-182", "last_ts": "2026-08-10T02:24:33", "last_type": "debrief", "last_wo": "WO-fill-organ-house--claude-ledger", "age_min": 27191, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-183", "last_ts": "2026-08-10T02:24:37", "last_type": "debrief", "last_wo": "WO-one-click-video-room", "age_min": 27191, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-184", "last_ts": "2026-08-10T02:24:37", "last_type": "debrief", "last_wo": "WO-one-intake-converge-capture", "age_min": 27191, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-185", "last_ts": "2026-08-10T02:34:22", "last_type": "debrief", "last_wo": "WO-orchestrator-info-pile-audit", "age_min": 27181, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-186", "last_ts": "2026-08-10T02:34:23", "last_type": "debrief", "last_wo": "WO-orphan-widgets-decision", "age_min": 27181, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-187", "last_ts": "2026-08-10T02:34:25", "last_type": "debrief", "last_wo": "WO-outside-rail-bootup-bootdown", "age_min": 27181, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-188", "last_ts": "2026-08-10T02:44:33", "last_type": "debrief", "last_wo": "WO-phased-checkoff-work-orders", "age_min": 27171, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-189", "last_ts": "2026-08-10T02:44:32", "last_type": "debrief", "last_wo": "WO-phone-bug-reporting", "age_min": 27171, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-19", "last_ts": "2026-08-06T04:38:39", "last_type": "debrief", "last_wo": "WO-dept-sales-collateral-lib", "age_min": 32817, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-190", "last_ts": "2026-08-10T02:44:37", "last_type": "debrief", "last_wo": "WO-pillar-communication", "age_min": 27171, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-191", "last_ts": "2026-08-10T02:54:31", "last_type": "debrief", "last_wo": "WO-pillar-culture", "age_min": 27161, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-192", "last_ts": "2026-08-10T02:54:31", "last_type": "debrief", "last_wo": "WO-pillar-energy", "age_min": 27161, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-193", "last_ts": "2026-08-10T02:54:32", "last_type": "debrief", "last_wo": "WO-pillar-food", "age_min": 27161, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-194", "last_ts": "2026-08-10T03:04:24", "last_type": "debrief", "last_wo": "WO-pillar-governance", "age_min": 27151, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-195", "last_ts": "2026-08-10T03:04:27", "last_type": "debrief", "last_wo": "WO-pillar-knowledge", "age_min": 27151, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-196", "last_ts": "2026-08-10T03:04:28", "last_type": "debrief", "last_wo": "WO-pillar-manufacturing", "age_min": 27151, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-197", "last_ts": "2026-08-10T03:14:20", "last_type": "debrief", "last_wo": "WO-pillar-medicine", "age_min": 27141, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-198", "last_ts": "2026-08-10T03:14:23", "last_type": "debrief", "last_wo": "WO-pillar-security", "age_min": 27141, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-199", "last_ts": "2026-08-10T03:14:25", "last_type": "debrief", "last_wo": "WO-pillar-shelter", "age_min": 27141, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-2", "last_ts": "2026-08-06T01:20:23", "last_type": "debrief", "last_wo": "WO-cockpit-widgets-build", "age_min": 33015, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-20", "last_ts": "2026-08-06T04:54:06", "last_type": "debrief", "last_wo": "WO-dept-finance-mrr-gauge", "age_min": 32801, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-200", "last_ts": "2026-08-10T03:24:26", "last_type": "debrief", "last_wo": "WO-pillar-trade", "age_min": 27131, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-201", "last_ts": "2026-08-10T03:24:26", "last_type": "debrief", "last_wo": "WO-pillar-transportation", "age_min": 27131, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-202", "last_ts": "2026-08-10T03:24:28", "last_type": "debrief", "last_wo": "WO-pillar-water", "age_min": 27131, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-203", "last_ts": "2026-08-10T03:34:26", "last_type": "debrief", "last_wo": "WO-recorded-call-spine", "age_min": 27121, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-204", "last_ts": "2026-08-10T03:34:28", "last_type": "debrief", "last_wo": "WO-registry-of-registries", "age_min": 27121, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-205", "last_ts": "2026-08-10T03:34:29", "last_type": "debrief", "last_wo": "WO-repair-ollama-llama-server", "age_min": 27121, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-206", "last_ts": "2026-08-10T03:44:31", "last_type": "debrief", "last_wo": "WO-revitalize-old-spine", "age_min": 27111, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-207", "last_ts": "2026-08-10T03:44:31", "last_type": "debrief", "last_wo": "WO-road-rig-van-then-bus-define", "age_min": 27111, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-208", "last_ts": "2026-08-10T03:44:34", "last_type": "debrief", "last_wo": "WO-role-registry-from-pcf", "age_min": 27111, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-209", "last_ts": "2026-08-10T03:54:39", "last_type": "debrief", "last_wo": "WO-room-feed-mirror", "age_min": 27101, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-21", "last_ts": "2026-08-06T06:12:58", "last_type": "debrief", "last_wo": "WO-autonomous-bug-fix-loop", "age_min": 32722, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-210", "last_ts": "2026-08-10T03:54:39", "last_type": "debrief", "last_wo": "WO-scoped-contributor-guild", "age_min": 27101, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-211", "last_ts": "2026-08-10T03:54:39", "last_type": "debrief", "last_wo": "WO-screenshot-b-widgets", "age_min": 27101, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-212", "last_ts": "2026-08-10T04:04:26", "last_type": "debrief", "last_wo": "WO-sign-bug-attachment-display", "age_min": 27091, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-213", "last_ts": "2026-08-10T04:04:26", "last_type": "debrief", "last_wo": "WO-signal-forge-music-define", "age_min": 27091, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-214", "last_ts": "2026-08-10T04:04:28", "last_type": "debrief", "last_wo": "WO-signal-forge-music", "age_min": 27091, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-215", "last_ts": "2026-08-10T04:14:17", "last_type": "debrief", "last_wo": "WO-skeleton-revival-audit", "age_min": 27081, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-216", "last_ts": "2026-08-10T04:14:19", "last_type": "debrief", "last_wo": "WO-speaking-tour-onboarding-define", "age_min": 27081, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-217", "last_ts": "2026-08-10T04:14:20", "last_type": "debrief", "last_wo": "WO-spine-attach-all", "age_min": 27081, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-218", "last_ts": "2026-08-10T04:24:19", "last_type": "debrief", "last_wo": "WO-stock-check-dev-lens", "age_min": 27071, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-219", "last_ts": "2026-08-10T04:24:19", "last_type": "debrief", "last_wo": "WO-stranger-walkthrough-record", "age_min": 27071, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-22", "last_ts": "2026-08-06T05:51:58", "last_type": "debrief", "last_wo": "WO-agent-os-upgrades-from-school", "age_min": 32743, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-220", "last_ts": "2026-08-10T04:24:21", "last_type": "debrief", "last_wo": "WO-supply-card-quality-gate", "age_min": 27071, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-221", "last_ts": "2026-08-10T04:34:43", "last_type": "debrief", "last_wo": "WO-supply-lesson-add-production-watchdog-widget-create-a-20260806-052842", "age_min": 27061, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-222", "last_ts": "2026-08-10T04:34:45", "last_type": "debrief", "last_wo": "WO-supply-lesson-araya-as-the-agent-harness-position-ara-20260806-052842", "age_min": 27061, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-223", "last_ts": "2026-08-10T04:34:47", "last_type": "debrief", "last_wo": "WO-supply-lesson-autonomous-loops-as-skills-convert-buil-20260806-052842", "age_min": 27060, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-224", "last_ts": "2026-08-10T10:16:55", "last_type": "debrief", "last_wo": "WO-supply-lesson-implement-the-25-minute-decision-dashbo-20260806-052842", "age_min": 26718, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-225", "last_ts": "2026-08-10T10:16:55", "last_type": "debrief", "last_wo": "WO-supply-lesson-widget-context-injection-each-dashboard-20260806-052842", "age_min": 26718, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-226", "last_ts": "2026-08-10T10:16:55", "last_type": "debrief", "last_wo": "WO-supply-lesson-key-separation-protocol-immediately-rev-20260806-052842", "age_min": 26718, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-227", "last_ts": "2026-08-10T10:34:28", "last_type": "debrief", "last_wo": "WO-tenant-araya-walkthrough", "age_min": 26701, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-228", "last_ts": "2026-08-10T10:34:28", "last_type": "debrief", "last_wo": "WO-testimonials-rachel-johnny", "age_min": 26701, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-229", "last_ts": "2026-08-10T10:34:30", "last_type": "debrief", "last_wo": "WO-the-4-5-categories-define", "age_min": 26701, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-23", "last_ts": "2026-08-06T05:54:17", "last_type": "debrief", "last_wo": "WO-araya-walkthrough-coach", "age_min": 32741, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-230", "last_ts": "2026-08-10T10:44:24", "last_type": "debrief", "last_wo": "WO-the-device-store-gadgets-define", "age_min": 26691, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-231", "last_ts": "2026-08-10T10:44:24", "last_type": "debrief", "last_wo": "WO-thumb-drive-packout", "age_min": 26691, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-232", "last_ts": "2026-08-10T10:44:27", "last_type": "debrief", "last_wo": "WO-tune-file-add-ux", "age_min": 26691, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-233", "last_ts": "2026-08-10T10:54:32", "last_type": "debrief", "last_wo": "WO-tune-tenant-interfaces", "age_min": 26681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-234", "last_ts": "2026-08-10T10:54:32", "last_type": "debrief", "last_wo": "WO-unified-tiering-ssot", "age_min": 26681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-235", "last_ts": "2026-08-10T10:54:32", "last_type": "debrief", "last_wo": "WO-vault-file-ops-define", "age_min": 26681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-236", "last_ts": "2026-08-10T11:04:32", "last_type": "debrief", "last_wo": "WO-vault-settings", "age_min": 26671, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-237", "last_ts": "2026-08-10T11:04:32", "last_type": "debrief", "last_wo": "WO-vault-ungate-previewer", "age_min": 26671, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-238", "last_ts": "2026-08-10T11:04:36", "last_type": "debrief", "last_wo": "WO-vin-stamp-machine", "age_min": 26671, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-239", "last_ts": "2026-08-10T11:14:36", "last_type": "debrief", "last_wo": "WO-watcher-agents", "age_min": 26661, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-24", "last_ts": "2026-08-06T06:34:21", "last_type": "debrief", "last_wo": "WO-case-intake-front-door", "age_min": 32701, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-240", "last_ts": "2026-08-10T11:14:38", "last_type": "debrief", "last_wo": "WO-widget-json-role-filtering", "age_min": 26661, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-241", "last_ts": "2026-08-10T11:14:41", "last_type": "debrief", "last_wo": "WO-widget-out-agent-activity", "age_min": 26661, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-242", "last_ts": "2026-08-10T11:24:29", "last_type": "debrief", "last_wo": "WO-problem-census-engine", "age_min": 26651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-243", "last_ts": "2026-08-10T11:24:31", "last_type": "debrief", "last_wo": "WO-widget-out-booking", "age_min": 26651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-244", "last_ts": "2026-08-10T11:24:34", "last_type": "debrief", "last_wo": "WO-widget-out-files", "age_min": 26651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-245", "last_ts": "2026-08-10T11:34:35", "last_type": "debrief", "last_wo": "WO-widget-out-orders", "age_min": 26641, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-246", "last_ts": "2026-08-10T11:34:38", "last_type": "debrief", "last_wo": "WO-widget-out-revenue", "age_min": 26641, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-247", "last_ts": "2026-08-10T11:34:40", "last_type": "debrief", "last_wo": "WO-widget-split-program", "age_min": 26641, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-248", "last_ts": "2026-08-10T11:44:35", "last_type": "debrief", "last_wo": "WO-fleet-queue-pipe-and-timer", "age_min": 26631, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-249", "last_ts": "2026-08-10T11:44:37", "last_type": "debrief", "last_wo": "WO-worktree-graveyard-sweep", "age_min": 26631, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-25", "last_ts": "2026-08-06T06:55:45", "last_type": "debrief", "last_wo": "WO-catalog-araya-fns", "age_min": 32680, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-250", "last_ts": "2026-08-10T11:44:40", "last_type": "debrief", "last_wo": "WO-xp-consolidation", "age_min": 26631, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-251", "last_ts": "2026-08-10T11:54:26", "last_type": "debrief", "last_wo": "WO-fleet-log-key-rotate", "age_min": 26621, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-252", "last_ts": "2026-08-10T11:54:29", "last_type": "debrief", "last_wo": "WO-social-reels-chatroom", "age_min": 26621, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-26", "last_ts": "2026-08-06T06:53:33", "last_type": "debrief", "last_wo": "WO-catalog-dashboard-fns", "age_min": 32682, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-266", "last_ts": "2026-08-10T12:44:18", "last_type": "debrief", "last_wo": "WO-developer-ai-cyclotron-access", "age_min": 26571, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-267", "last_ts": "2026-08-10T12:44:19", "last_type": "debrief", "last_wo": "WO-spreadsheet-control-surface", "age_min": 26571, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-27", "last_ts": "2026-08-06T07:23:05", "last_type": "debrief", "last_wo": "WO-claim-rights-role-gate", "age_min": 32652, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-278", "last_ts": "2026-08-10T19:20:10", "last_type": "debrief", "last_wo": "WO-fleet-engine-triggers", "age_min": 26175, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-28", "last_ts": "2026-08-06T07:17:44", "last_type": "claim", "last_wo": "WO-consolidate-todo-surfaces", "age_min": 32658, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-284", "last_ts": "2026-08-10T13:44:20", "last_type": "debrief", "last_wo": "WO-project-context-index", "age_min": 26511, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-29", "last_ts": "2026-08-06T07:21:13", "last_type": "claim", "last_wo": "WO-contacts-top150-report", "age_min": 32654, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-290", "last_ts": "2026-08-10T14:04:05", "last_type": "claim", "last_wo": "WO-pr-direction-filter", "age_min": 26491, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-293", "last_ts": "2026-08-10T14:14:14", "last_type": "claim", "last_wo": "WO-wo-system-hardening", "age_min": 26481, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-299", "last_ts": "2026-08-10T14:34:05", "last_type": "claim", "last_wo": "WO-agent-debrief-report", "age_min": 26461, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-3", "last_ts": "2026-08-05T22:52:24", "last_type": "debrief", "last_wo": "WO-library-tag-taxonomy", "age_min": 33163, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-302", "last_ts": "2026-08-10T14:44:14", "last_type": "claim", "last_wo": "WO-wo-spine-ux", "age_min": 26451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-303", "last_ts": "2026-08-10T14:44:12", "last_type": "claim", "last_wo": "WO-devcenter-the-room", "age_min": 26451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-304", "last_ts": "2026-08-10T14:44:11", "last_type": "claim", "last_wo": "WO-devcenter-see-whats-needed", "age_min": 26451, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-305", "last_ts": "2026-08-10T14:54:50", "last_type": "claim", "last_wo": "WO-mission-elements-partial-xp", "age_min": 26440, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-306", "last_ts": "2026-08-10T14:54:53", "last_type": "claim", "last_wo": "WO-xp-floors-and-rooms", "age_min": 26440, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-307", "last_ts": "2026-08-10T14:54:51", "last_type": "claim", "last_wo": "WO-watcher-meta", "age_min": 26440, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-308", "last_ts": "2026-08-10T15:04:05", "last_type": "claim", "last_wo": "WO-public-board-access-filter", "age_min": 26431, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-320", "last_ts": "2026-08-10T15:44:05", "last_type": "claim", "last_wo": "WO-standup-grist-living-tree", "age_min": 26391, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-323", "last_ts": "2026-08-10T15:54:05", "last_type": "claim", "last_wo": "WO-fleet-delivery-hardening", "age_min": 26381, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-329", "last_ts": "2026-08-10T16:14:06", "last_type": "claim", "last_wo": "WO-file-indexing-ingest", "age_min": 26361, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-338", "last_ts": "2026-08-10T16:44:20", "last_type": "debrief", "last_wo": "WO-opencode-headless-permission-bypass", "age_min": 26331, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-350", "last_ts": "2026-08-10T17:24:21", "last_type": "debrief", "last_wo": "WO-youtube-transcription-processor", "age_min": 26291, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-356", "last_ts": "2026-08-10T17:44:15", "last_type": "debrief", "last_wo": "WO-cross-ai-bootstrap-relay", "age_min": 26271, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-365", "last_ts": "2026-08-10T18:14:15", "last_type": "debrief", "last_wo": "WO-rescue-stale-pr-cluster", "age_min": 26241, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-37", "last_ts": "2026-08-06T10:09:50", "last_type": "debrief", "last_wo": "WO-lesson-Eq8JgI-09-monitor-and-feed-bac", "age_min": 32485, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-38", "last_ts": "2026-08-06T10:09:52", "last_type": "debrief", "last_wo": "WO-lesson-vJEy3n-03-pin-and-prioritize", "age_min": 32485, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-39", "last_ts": "2026-08-06T10:09:52", "last_type": "debrief", "last_wo": "WO-supply-tick", "age_min": 32485, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-4", "last_ts": "2026-08-05T23:00:21", "last_type": "debrief", "last_wo": "WO-magical-music-dashboard", "age_min": 33155, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-40", "last_ts": "2026-08-06T10:57:22", "last_type": "debrief", "last_wo": "WO-widget-out-links", "age_min": 32438, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-41", "last_ts": "2026-08-06T10:53:45", "last_type": "claim", "last_wo": "WO-widget-out-orders", "age_min": 32442, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-42", "last_ts": "2026-08-06T10:15:05", "last_type": "debrief", "last_wo": "WO-nightly-consolidator", "age_min": 32480, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-43", "last_ts": "2026-08-06T10:15:06", "last_type": "debrief", "last_wo": "WO-node-harness-test-utility", "age_min": 32480, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-44", "last_ts": "2026-08-06T10:15:06", "last_type": "debrief", "last_wo": "WO-lesson-vJEy3n-08-work-from-phone", "age_min": 32480, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-45", "last_ts": "2026-08-06T13:20:15", "last_type": "done", "last_wo": "WO-widget-out-forges", "age_min": 32295, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-46", "last_ts": "2026-08-06T13:54:33", "last_type": "claim", "last_wo": "WO-widget-out-agent-activity", "age_min": 32261, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-47", "last_ts": "2026-08-06T17:56:34", "last_type": "claim", "last_wo": "WO-promotion-crank", "age_min": 32019, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-48", "last_ts": "2026-08-06T18:04:36", "last_type": "claim", "last_wo": "WO-app-interaction-map", "age_min": 32011, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-49", "last_ts": "2026-08-06T17:57:42", "last_type": "claim", "last_wo": "WO-reconcile-builder-standard-chrome", "age_min": 32018, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-5", "last_ts": "2026-08-05T23:19:13", "last_type": "done", "last_wo": "WO-transcription-state-entry-research", "age_min": 33136, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-50", "last_ts": "2026-08-06T18:58:29", "last_type": "debrief", "last_wo": "WO-stale-worktree-cleanup", "age_min": 31957, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-51", "last_ts": "2026-08-06T18:55:50", "last_type": "debrief", "last_wo": "WO-araya-capture-endpoint", "age_min": 31959, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-52", "last_ts": "2026-08-06T19:09:56", "last_type": "debrief", "last_wo": "WO-startup-org-blueprint", "age_min": 31945, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-53", "last_ts": "2026-08-06T19:52:36", "last_type": "debrief", "last_wo": "WO-youtube-school", "age_min": 31903, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-54", "last_ts": "2026-08-06T19:56:32", "last_type": "debrief", "last_wo": "WO-work-order-factory", "age_min": 31899, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-55", "last_ts": "2026-08-06T19:55:51", "last_type": "debrief", "last_wo": "WO-yt-holding-company-folders", "age_min": 31899, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-56", "last_ts": "2026-08-06T20:34:35", "last_type": "debrief", "last_wo": "WO-per-user-app-access-tree", "age_min": 31861, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-57", "last_ts": "2026-08-06T20:51:30", "last_type": "debrief", "last_wo": "WO-dm-large-text-reader", "age_min": 31844, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-58", "last_ts": "2026-08-06T20:26:17", "last_type": "debrief", "last_wo": "WO-in-app-callback-recording", "age_min": 31869, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-59", "last_ts": "2026-08-06T21:23:59", "last_type": "debrief", "last_wo": "WO-metrics-engine", "age_min": 31811, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-6", "last_ts": "2026-08-05T23:26:52", "last_type": "debrief", "last_wo": "WO-library-surface-form", "age_min": 33128, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-60", "last_ts": "2026-08-06T21:18:19", "last_type": "debrief", "last_wo": "WO-builder-engine", "age_min": 31817, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-61", "last_ts": "2026-08-06T21:30:46", "last_type": "debrief", "last_wo": "WO-basics-gaps", "age_min": 31804, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-73", "last_ts": "2026-08-06T22:49:31", "last_type": "debrief", "last_wo": "WO-ubiquitous-import-export", "age_min": 31726, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-74", "last_ts": "2026-08-06T22:45:14", "last_type": "debrief", "last_wo": "WO-audit-widget-agents", "age_min": 31730, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-75", "last_ts": "2026-08-06T22:52:33", "last_type": "debrief", "last_wo": "WO-widget-forges-promote", "age_min": 31723, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-76", "last_ts": "2026-08-06T23:36:34", "last_type": "debrief", "last_wo": "WO-audit-widget-forges", "age_min": 31679, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-77", "last_ts": "2026-08-06T23:33:45", "last_type": "debrief", "last_wo": "WO-audit-widget-lawschool", "age_min": 31682, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-78", "last_ts": "2026-08-06T23:37:39", "last_type": "debrief", "last_wo": "WO-audit-widget-files", "age_min": 31678, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-79", "last_ts": "2026-08-07T01:18:27", "last_type": "debrief", "last_wo": "WO-audit-widget-orders", "age_min": 31577, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-8", "last_ts": "2026-08-06T00:02:50", "last_type": "debrief", "last_wo": "WO-one-verdict-per-entity", "age_min": 33092, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-80", "last_ts": "2026-08-07T01:16:10", "last_type": "claim", "last_wo": "WO-audit-widget-park-bin", "age_min": 31579, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-81", "last_ts": "2026-08-07T01:18:27", "last_type": "debrief", "last_wo": "WO-audit-widget-mission", "age_min": 31577, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-82", "last_ts": "2026-08-07T14:14:03", "last_type": "claim", "last_wo": "WO-audit-widget-tools", "age_min": 30801, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-83", "last_ts": "2026-08-07T14:14:04", "last_type": "claim", "last_wo": "WO-audit-widget-voice", "age_min": 30801, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-84", "last_ts": "2026-08-07T14:14:04", "last_type": "claim", "last_wo": "WO-audit-widget-wo-board", "age_min": 30801, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-85", "last_ts": "2026-08-07T14:54:06", "last_type": "claim", "last_wo": "WO-fix-cockpit-mount-planner", "age_min": 30761, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-86", "last_ts": "2026-08-07T14:54:04", "last_type": "claim", "last_wo": "WO-fix-cockpit-mount-contacts", "age_min": 30761, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-87", "last_ts": "2026-08-07T14:54:05", "last_type": "claim", "last_wo": "WO-fix-cockpit-mount-leads", "age_min": 30761, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-88", "last_ts": "2026-08-07T15:34:04", "last_type": "claim", "last_wo": "WO-dogfood-doc-consolidation", "age_min": 30721, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-89", "last_ts": "2026-08-07T15:34:05", "last_type": "claim", "last_wo": "WO-fleet-tier3-watcher", "age_min": 30721, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-9", "last_ts": "2026-08-06T00:38:57", "last_type": "debrief", "last_wo": "WO-cockpit-cloud-convergence", "age_min": 33056, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-90", "last_ts": "2026-08-07T15:34:05", "last_type": "claim", "last_wo": "WO-framework-state-caretag-schema", "age_min": 30721, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-900-live", "last_ts": "2026-08-10T19:58:18", "last_type": "debrief", "last_wo": "WO-canonical-ux-patterns", "age_min": 26137, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-901-manual", "last_ts": "2026-08-10T23:09:08", "last_type": "debrief", "last_wo": "WO-attach-share-contextual", "age_min": 25946, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-902-manual", "last_ts": "2026-08-10T23:21:02", "last_type": "debrief", "last_wo": "WO-builder-green-projects", "age_min": 25934, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-903-manual", "last_ts": "2026-08-10T22:56:34", "last_type": "debrief", "last_wo": "WO-builder-rank-economy-sec-safe", "age_min": 25959, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-904-manual", "last_ts": "2026-08-11T00:34:19", "last_type": "debrief", "last_wo": "WO-commander-log-news-feed", "age_min": 25861, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-905-manual", "last_ts": "2026-08-11T09:02:48", "last_type": "debrief", "last_wo": "WO-green-project-storage-schema", "age_min": 25352, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-906-manual", "last_ts": "2026-08-11T04:33:48", "last_type": "debrief", "last_wo": "WO-drawer-is-the-everything-menu", "age_min": 25621, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-907-manual", "last_ts": "2026-08-11T04:36:52", "last_type": "debrief", "last_wo": "WO-dashboard-mobile-unsquish", "age_min": 25618, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-91", "last_ts": "2026-08-07T16:14:07", "last_type": "claim", "last_wo": "WO-supply-lesson-araya-as-the-agent-harness-position-ara-20260806-052842", "age_min": 30681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-92", "last_ts": "2026-08-07T16:14:05", "last_type": "claim", "last_wo": "WO-stranger-walkthrough-record", "age_min": 30681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-93", "last_ts": "2026-08-07T16:14:09", "last_type": "claim", "last_wo": "WO-supply-lesson-autonomous-loops-as-skills-convert-buil-20260806-052842", "age_min": 30681, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-94", "last_ts": "2026-08-07T16:44:10", "last_type": "claim", "last_wo": "WO-every-dead-end-calls-us", "age_min": 30651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-95", "last_ts": "2026-08-07T16:44:11", "last_type": "claim", "last_wo": "WO-fractal-benchmarking-harness", "age_min": 30651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-96", "last_ts": "2026-08-07T16:44:11", "last_type": "claim", "last_wo": "WO-github-failure-feedback", "age_min": 30651, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-97", "last_ts": "2026-08-07T18:24:05", "last_type": "claim", "last_wo": "WO-html-placement-gate", "age_min": 30551, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-98", "last_ts": "2026-08-07T18:24:06", "last_type": "claim", "last_wo": "WO-idea-intake-router", "age_min": 30551, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-99", "last_ts": "2026-08-07T18:24:07", "last_type": "claim", "last_wo": "WO-inside-oracle-broker", "age_min": 30551, "live": false, "cards": [], "park_count": 0 }, { "seat": "opencode-big-pickle", "last_ts": "2026-08-11T19:18:30", "last_type": "claim", "last_wo": "WO-builder-agent-delegation", "age_min": 24737, "live": false, "cards": [], "park_count": 0 }, { "seat": "opus-1", "last_ts": "2026-08-05T23:14:03", "last_type": "debrief", "last_wo": "", "age_min": 33141, "live": false, "cards": [], "park_count": 0 }, { "seat": "opus-cloud-tier", "last_ts": "2026-08-06T00:55:10", "last_type": "progress", "last_wo": "WO-cloud-agent-runner", "age_min": 33040, "live": false, "cards": [], "park_count": 0 }, { "seat": "opus-s414", "last_ts": "2026-08-06T01:48:21", "last_type": "debrief", "last_wo": "", "age_min": 32987, "live": false, "cards": [], "park_count": 0 }, { "seat": "opus-widget-census", "last_ts": "2026-08-06T01:44:28", "last_type": "progress", "last_wo": "WO-cloud-agent-runner", "age_min": 32991, "live": false, "cards": [], "park_count": 0 }, { "seat": "orphan-watchdog", "last_ts": "2026-08-27T17:57:12", "last_type": "orphan-warn", "last_wo": "WO-mloop-canary", "age_min": 1778, "live": false, "cards": [], "park_count": 0 }, { "seat": "promoter-trigger", "last_ts": "2026-08-06T10:14:41", "last_type": "promoted", "last_wo": "WO-recruit-team-mechanic", "age_min": 32481, "live": false, "cards": [], "park_count": 0 }, { "seat": "selftest", "last_ts": "2026-07-31T15:34:35", "last_type": "done", "last_wo": "WO-strapping-selftest", "age_min": 40801, "live": false, "cards": [], "park_count": 0 }, { "seat": "sim-holder", "last_ts": "2026-08-05T23:29:44", "last_type": "claim", "last_wo": "WO-permission-tiers-enforced", "age_min": 33126, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-claude", "last_ts": "2026-08-11T13:49:53", "last_type": "debrief", "last_wo": "", "age_min": 25065, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-fleet-1", "last_ts": "2026-08-05T21:39:32", "last_type": "debrief", "last_wo": "WO-auto-sideline-stale-wos", "age_min": 33236, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-fleet-2", "last_ts": "2026-08-05T21:30:26", "last_type": "debrief", "last_wo": "WO-agents-md-standard-alignment", "age_min": 33245, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-fleet-3", "last_ts": "2026-08-05T21:25:14", "last_type": "debrief", "last_wo": "WO-abilities-manifest-5in5out", "age_min": 33250, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-overkor", "last_ts": "2026-08-05T22:00:46", "last_type": "debrief", "last_wo": "WO-overkor-orchestrator-consolidation", "age_min": 33214, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-test-fix", "last_ts": "2026-08-06T22:14:35", "last_type": "debrief", "last_wo": "WO-commander-dashboard-ONE", "age_min": 31761, "live": false, "cards": [], "park_count": 0 }, { "seat": "t1-test-verify", "last_ts": "2026-08-05T22:34:48", "last_type": "claim", "last_wo": "WO-permission-tiers-enforced", "age_min": 33180, "live": false, "cards": [], "park_count": 0 }, { "seat": "test-genuine", "last_ts": "2026-08-06T04:45:07", "last_type": "blocked", "last_wo": "WO-permission-tiers-enforced", "age_min": 32810, "live": false, "cards": [], "park_count": 0 }, { "seat": "test-seat", "last_ts": "2026-08-06T13:45:27", "last_type": "debrief", "last_wo": "WO-zzz-close-test", "age_min": 32270, "live": false, "cards": [], "park_count": 0 }, { "seat": "test-seat-a", "last_ts": "2026-08-06T05:45:27", "last_type": "claim", "last_wo": "WO-t1-test-no-status", "age_min": 32750, "live": false, "cards": [], "park_count": 0 }, { "seat": "test-verify", "last_ts": "2026-08-05T18:40:46", "last_type": "debrief", "last_wo": "WO-ZZTEST-archive-check2", "age_min": 33414, "live": false, "cards": [], "park_count": 0 }, { "seat": "wo-triggers", "last_ts": "2026-08-06T10:56:51", "last_type": "note", "last_wo": "", "age_min": 32438, "live": false, "cards": [], "park_count": 0 } ], "park": [], "feed": [ { "ts": "2026-08-28T20:13:54", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-28T18:10:18", "from": "S468-widgets", "to": "debrief-lot", "type": "debrief", "wo": "", "msg": "" }, { "ts": "2026-08-28T16:07:32", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-28T15:07:20", "from": "CP3-legal", "to": "debrief-lot", "type": "debrief", "wo": "", "msg": "" }, { "ts": "2026-08-28T12:09:16", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-28T12:09:16", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-28T12:09:16", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-28T12:07:06", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-28T08:53:40", "from": "CP3-legal", "to": "debrief-lot", "type": "debrief", "wo": "", "msg": "" }, { "ts": "2026-08-28T08:08:58", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-28T08:08:58", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-28T08:08:58", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-28T08:07:08", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-28T04:09:52", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-28T04:09:52", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-28T04:09:52", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-28T04:07:15", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-28T00:09:21", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-28T00:09:21", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-28T00:09:21", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-28T00:07:13", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-27T17:57:28", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-27T17:57:28", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-27T17:57:28", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-27T17:57:12", "from": "orphan-watchdog", "to": "all", "type": "orphan-warn", "wo": "WO-mloop-canary", "msg": "ORPHAN WARNING for seat 'aider-local': 1st pass: quiet 109m, no palette + no recent bus — only advances to release on a SUBSEQUENT run made WITH --release (state isn't saved otherwise); use --free WO-mloop-canary for a one-off human-authorized release now. Post a beat (DISPATCH.py beat WO-mloop-canary --from aider-local) to clear it, or it releases next pass." }, { "ts": "2026-08-27T16:07:22", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." }, { "ts": "2026-08-27T12:09:16", "from": "aider-local", "to": "debrief-lot", "type": "debrief", "wo": "WO-mloop-canary", "msg": "" }, { "ts": "2026-08-27T12:09:16", "from": "aider-local", "to": "all", "type": "done", "wo": "WO-mloop-canary", "msg": "local model edit via aider" }, { "ts": "2026-08-27T12:09:16", "from": "aider-local", "to": "all", "type": "progress", "wo": "WO-mloop-canary", "msg": "YELLOW_TIER_LOG: YELLOW_TIER: 'wo_close' is caution-level — logged but proceeding" }, { "ts": "2026-08-27T12:07:29", "from": "aider-local", "to": "all", "type": "claim", "wo": "WO-mloop-canary", "msg": "STRAPPING: fleet claiming 'WO-mloop-canary — M-loop canary — prove a free unit is alive' — on-rails (WO+bus+board)." } ], "stale_claims": [], "lightness": { "pile": 168, "open_wo": 168, "park_open": 0, "trend_points": 38, "delta_since_first": 122, "lighter": false, "ts": "2026-08-28T21:22:57" } }