npm - create-walle - Versions diffs - 0.9.31 → 0.9.32 - Mend

create-walle 0.9.31 → 0.9.32

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (99) hide show

package/template/claude-task-manager/docs/postgres-concurrency-dgx-spark.html ADDED Viewed

@@ -0,0 +1,407 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<title>CTM + Wall-E · Postgres, Concurrency &amp; the Supercomputer-as-a-Service Question</title>
+<style>
+  :root{
+    --bg:#0b0e14; --panel:#11161f; --panel2:#161d28; --ink:#e6edf3; --dim:#9aa7b8;
+    --line:#212a37; --accent:#5ec8ff; --accent2:#7ee787; --warn:#ffb86b; --bad:#ff7b72;
+    --grace:#76e0c2; --pg:#7aa2ff; --gpu:#9d7bff; --mono:"SF Mono",ui-monospace,"JetBrains Mono",Menlo,Consolas,monospace;
+  }
+  *{box-sizing:border-box}
+  html{scroll-behavior:smooth}
+  body{
+    margin:0;background:radial-gradient(1200px 700px at 80% -10%,#16202e 0%,var(--bg) 55%);
+    color:var(--ink);font:16px/1.6 -apple-system,BlinkMacSystemFont,"Segoe UI",Inter,Roboto,sans-serif;
+    -webkit-font-smoothing:antialiased;padding-bottom:6rem;
+  }
+  .wrap{max-width:1040px;margin:0 auto;padding:0 24px}
+  header.hero{padding:64px 24px 40px;max-width:1040px;margin:0 auto}
+  .kicker{font:600 12px/1 var(--mono);letter-spacing:.22em;text-transform:uppercase;color:var(--accent);margin-bottom:18px}
+  h1{font-size:40px;line-height:1.12;margin:0 0 16px;letter-spacing:-.02em;font-weight:740}
+  h1 .g{background:linear-gradient(100deg,var(--grace),var(--pg) 55%,var(--gpu));-webkit-background-clip:text;background-clip:text;color:transparent}
+  .sub{font-size:18px;color:var(--dim);max-width:74ch;margin:0}
+  .meta{margin-top:22px;font:500 13px/1.5 var(--mono);color:var(--dim)}
+  .meta b{color:var(--ink);font-weight:600}
+  h2{font-size:25px;letter-spacing:-.01em;margin:56px 0 8px;font-weight:700;scroll-margin-top:20px}
+  h2 .n{font:700 14px/1 var(--mono);color:var(--accent);margin-right:12px;vertical-align:2px}
+  h3{font-size:18px;margin:30px 0 8px;font-weight:660}
+  p{margin:12px 0}
+  a{color:var(--accent);text-decoration:none;border-bottom:1px solid #2c4a5e}
+  a:hover{border-color:var(--accent)}
+  .lead{color:var(--dim);font-size:16.5px;margin-top:4px}
+  code{font:13.5px/1.5 var(--mono);background:#0d141d;border:1px solid var(--line);border-radius:5px;padding:1px 6px;color:#cfe6ff}
+  strong{color:#fff;font-weight:660}
+  em{color:var(--ink);font-style:italic}
+  .panel{background:linear-gradient(180deg,var(--panel),#0e131b);border:1px solid var(--line);border-radius:14px;padding:22px 24px;margin:22px 0}
+  .tldr{border-left:3px solid var(--accent)}
+  .tldr h2{margin-top:0}
+  .grid2{display:grid;grid-template-columns:1fr 1fr;gap:16px}
+  .grid3{display:grid;grid-template-columns:repeat(3,1fr);gap:14px}
+  @media(max-width:780px){.grid2,.grid3{grid-template-columns:1fr}}
+  .card{background:var(--panel2);border:1px solid var(--line);border-radius:12px;padding:16px 18px}
+  .card h4{margin:0 0 8px;font-size:15px;font-weight:660;display:flex;align-items:center;gap:8px}
+  .card p{margin:6px 0;font-size:14.5px;color:var(--dim)}
+  .pill{display:inline-block;font:600 11px/1 var(--mono);padding:5px 9px;border-radius:999px;border:1px solid var(--line);color:var(--dim);background:#0d141d}
+  .dot{width:9px;height:9px;border-radius:50%;display:inline-block;flex:none}
+  table{width:100%;border-collapse:collapse;margin:18px 0;font-size:14px}
+  th,td{text-align:left;padding:11px 13px;border-bottom:1px solid var(--line);vertical-align:top}
+  th{font:600 12px/1 var(--mono);letter-spacing:.05em;text-transform:uppercase;color:var(--dim)}
+  tbody tr:hover{background:#0f1620}
+  td code{font-size:12.5px}
+  .yes{color:var(--accent2)} .no{color:var(--bad)} .meh{color:var(--warn)}
+  .callout{border:1px solid var(--line);border-radius:12px;padding:14px 18px;margin:18px 0;background:#0e1019}
+  .callout.warn{border-color:#5a4326;background:#1a1408}
+  .callout.good{border-color:#26503a;background:#0a1710}
+  .callout .h{font:600 12px/1 var(--mono);letter-spacing:.06em;text-transform:uppercase;margin-bottom:6px}
+  .callout.warn .h{color:var(--warn)} .callout.good .h{color:var(--accent2)}
+  .callout p{margin:4px 0;font-size:14.5px}
+  figure{margin:24px 0}
+  figcaption{font:500 12.5px/1.5 var(--mono);color:var(--dim);margin-top:10px;text-align:center}
+  svg{width:100%;height:auto;display:block}
+  .svgwrap{background:#0a0f17;border:1px solid var(--line);border-radius:14px;padding:18px}
+  ul.clean{list-style:none;padding:0;margin:12px 0}
+  ul.clean li{padding:7px 0 7px 26px;position:relative;color:var(--dim)}
+  ul.clean li::before{content:"";position:absolute;left:4px;top:14px;width:7px;height:7px;border-radius:50%;background:var(--accent)}
+  ul.clean li b{color:var(--ink)}
+  .toc{font:500 14px/1.9 var(--mono)}
+  .toc a{border:0;color:var(--dim);display:block}
+  .toc a:hover{color:var(--accent)}
+  .toc .num{color:var(--accent);display:inline-block;width:30px}
+  .legend{display:flex;gap:20px;flex-wrap:wrap;margin-top:14px;font:500 12.5px/1 var(--mono);color:var(--dim)}
+  .legend span{display:flex;align-items:center;gap:7px}
+  footer{margin-top:60px;padding-top:24px;border-top:1px solid var(--line);color:var(--dim);font-size:13.5px}
+  .src{font-size:13px;line-height:1.9}
+  .tag{font:600 10.5px/1 var(--mono);padding:4px 7px;border-radius:5px;border:1px solid var(--line);color:var(--dim)}
+  .tag.now{color:var(--accent2);border-color:#26503a}
+  .tag.soon{color:var(--warn);border-color:#5a4326}
+  .tag.far{color:var(--gpu);border-color:#3a2e5a}
+  hr{border:0;border-top:1px solid var(--line);margin:40px 0}
+  .big{font-size:30px;font-weight:740;letter-spacing:-.01em}
+  .num-strip{display:flex;gap:14px;flex-wrap:wrap;margin:18px 0}
+  .stat{flex:1;min-width:150px;background:var(--panel2);border:1px solid var(--line);border-radius:12px;padding:16px}
+  .stat .v{font-size:24px;font-weight:740;color:#fff}
+  .stat .l{font:500 12px/1.4 var(--mono);color:var(--dim);margin-top:4px}
+</style>
+</head>
+<body>
+<header class="hero">
+  <div class="kicker">CTM + Wall-E · Architecture Discussion · 2026-06-28</div>
+  <h1>Postgres, real concurrency, and the<br><span class="g">supercomputer-as-a-service</span> question</h1>
+  <p class="sub">An extension of the approved SQLite&nbsp;→&nbsp;Postgres migration spec. It asks a sharper question: once the data layer is async and networked, <em>how much concurrency do we actually have</em> — and what changes if CTM + Wall-E run as a multi-tenant service on a single dedicated AI box like an NVIDIA DGX&nbsp;Spark?</p>
+  <div class="meta">
+    Companion to <b>~/.claude/plans/let-s-discuss-do-online-frolicking-pascal.md</b> (Phases 0–5)<br>
+    Status: <b>discussion / design exploration</b> — not a commitment. Phase 0 async seam already shipped on <b>feat/db-async-seam</b>.
+  </div>
+</header>
+<div class="wrap">
+<div class="panel tldr">
+  <h2 style="border:0">TL;DR</h2>
+  <ul class="clean">
+    <li><b>The concurrency we have today is mostly <em>fake</em>.</b> One user, one machine — but dozens of background workers (harvest, backfill, import, embeddings, approval agent) all contending for a <em>single SQLite writer</em>. That contention <em>is</em> the freeze story.</li>
+    <li><b>Postgres doesn't make things faster — it removes the single-writer ceiling.</b> MVCC lets readers and writers run concurrently. The async seam (Phase 0) is what lets Node actually use that concurrency instead of blocking the event loop on it.</li>
+    <li><b>Real concurrency only appears when you go multi-device / multi-agent.</b> That's when SQLite's file-lock model genuinely breaks and a server engine becomes <em>required</em>, not just nicer.</li>
+    <li><b>The DGX Spark angle is real, and oddly well-matched.</b> One box co-locates Postgres + pgvector + GPU embedding/inference in 128&nbsp;GB unified memory. EDB's GPU-accelerated Postgres vector extension <em>explicitly lists the GB10 chip</em> (the one inside Spark) as supported. It turns "hosted DB + cloud LLM calls" into "one local node does all of it."</li>
+    <li><b>Honest verdict:</b> a Spark is <em>overkill for one user</em> and <em>underkill for a real fleet</em>. It's compelling in exactly one scenario — a <b>private, always-on, multi-device + heavy-local-inference</b> deployment where you want everything on hardware you own. Worth designing toward; not worth buying for today's load.</li>
+  </ul>
+</div>
+<div class="panel toc">
+  <a href="#concurrency"><span class="num">01</span> Where does "concurrency" actually come from?</a>
+  <a href="#wall"><span class="num">02</span> Why SQLite hits a wall under real concurrency</a>
+  <a href="#pg"><span class="num">03</span> The Postgres concurrency model (and why async is the unlock)</a>
+  <a href="#spark"><span class="num">04</span> The DGX Spark vision: one box, every subsystem</a>
+  <a href="#arch"><span class="num">05</span> Reference architecture</a>
+  <a href="#gpu"><span class="num">06</span> What the GPU actually buys you</a>
+  <a href="#sizing"><span class="num">07</span> Capacity &amp; sizing — rough numbers</a>
+  <a href="#phasing"><span class="num">08</span> How this extends the Phase 0–5 plan</a>
+  <a href="#risks"><span class="num">09</span> Risks &amp; honest caveats</a>
+  <a href="#verdict"><span class="num">10</span> Decision matrix: when is this worth it?</a>
+</div>
+<!-- ───────────────────────────── 01 ───────────────────────────── -->
+<h2 id="concurrency"><span class="n">01</span>Where does "concurrency" actually come from?</h2>
+<p class="lead">Before designing for "more concurrency," be precise about which kind. CTM/Wall-E has three very different sources, and they live on opposite ends of the difficulty spectrum.</p>
+<div class="grid3">
+  <div class="card">
+    <h4><span class="dot" style="background:var(--accent2)"></span>Intra-process <span class="tag now">today</span></h4>
+    <p>One Node process, many <em>async tasks</em>: SSE streams, PTY pumps, the queue engine, the approval agent, conversation catch-up polls. Concurrency is cooperative — anything synchronous blocks <em>all</em> of it.</p>
+  </div>
+  <div class="card">
+    <h4><span class="dot" style="background:var(--accent2)"></span>Worker threads <span class="tag now">today</span></h4>
+    <p><code>read-pool-worker.js</code> + <code>db-owner-worker.js</code> already move heavy reads/writes off the main loop. But the writer is still <em>one serial lane</em> (<code>sqlite-owner-write-queue.js</code>) because SQLite allows one writer.</p>
+  </div>
+  <div class="card">
+    <h4><span class="dot" style="background:var(--gpu)"></span>Multi-client <span class="tag far">future</span></h4>
+    <p>Phones, laptops, and <em>autonomous agents</em> all writing to the same brain at once. This is genuine parallelism — and the only kind that <em>forces</em> a server-class database.</p>
+  </div>
+</div>
+<div class="callout">
+  <div class="h">The key reframe</div>
+  <p>Today's "concurrency" is really <strong>contention</strong>: ~a dozen background jobs queuing behind one SQLite writer and one event loop. Phase 0's async seam + Postgres MVCC turn that queue into real parallel execution. <em>Then</em> multi-device makes the parallelism genuinely external — which is the thing that justifies the whole migration beyond just killing freezes.</p>
+</div>
+<!-- ───────────────────────────── 02 ───────────────────────────── -->
+<h2 id="wall"><span class="n">02</span>Why SQLite hits a wall under real concurrency</h2>
+<p class="lead">SQLite is superb for a single embedded user. Its design choices become liabilities the moment concurrency stops being cooperative.</p>
+<table>
+  <thead><tr><th>Dimension</th><th>SQLite (today)</th><th>Under real concurrency</th></tr></thead>
+  <tbody>
+    <tr><td><b>Writers</b></td><td>Exactly one at a time; WAL serializes</td><td class="no">N agents/devices → write-lock storms, retry backoff, the <code>sqlite-write-lock.js</code> machinery exists <em>precisely</em> to paper over this</td></tr>
+    <tr><td><b>Driver model</b></td><td><code>better-sqlite3</code> is <em>synchronous</em></td><td class="no">Any slow query blocks Node's single thread — a network DB call this way would freeze <em>worse</em></td></tr>
+    <tr><td><b>Reach</b></td><td>A file on local disk (worse on Dropbox/synced volumes)</td><td class="no">No second device can open the same file safely; no network protocol</td></tr>
+    <tr><td><b>Checkpoints</b></td><td>Manual WAL checkpoint, <code>wal_autocheckpoint=0</code></td><td class="meh">457 ms–3 s stalls observed; tuned around, never eliminated</td></tr>
+    <tr><td><b>Vector / FTS</b></td><td><code>sqlite-vec</code> int8 + FTS5, in-process</td><td class="meh">CPU-bound, single-host; can't be shared or GPU-accelerated</td></tr>
+  </tbody>
+</table>
+<p>None of this is a knock on SQLite — it's the right tool for an embedded single-writer app. The point is structural: <strong>the moment you want two writers or two devices, every one of these rows flips from "fine" to "fundamental blocker."</strong></p>
+<!-- ───────────────────────────── 03 ───────────────────────────── -->
+<h2 id="pg"><span class="n">03</span>The Postgres concurrency model (and why async is the unlock)</h2>
+<p class="lead">Postgres replaces "one writer + a file lock" with MVCC: each transaction sees a consistent snapshot, readers never block writers, and writers only conflict on the same row. That is exactly the model multi-agent state needs.</p>
+<div class="grid2">
+  <div class="card">
+    <h4><span class="dot" style="background:var(--pg)"></span>What Postgres gives</h4>
+    <ul class="clean" style="margin:0">
+      <li><b>MVCC</b> — concurrent readers + writers, no global lock</li>
+      <li><b>Connection pool</b> (pgbouncer) — many clients, bounded backend processes</li>
+      <li><b>Server-side compute</b> — heavy reads run in the engine, not in a Node worker shipping rows</li>
+      <li><b>Retire</b> <code>sqlite-write-lock.js</code>, <code>sqlite-owner-write-queue.js</code>, <code>db-owner-worker.js</code>, storage-policy guards</li>
+    </ul>
+  </div>
+  <div class="card">
+    <h4><span class="dot" style="background:var(--warn)"></span>What Postgres does <em>not</em> give for free</h4>
+    <ul class="clean" style="margin:0">
+      <li><b>Latency</b> — every in-process read becomes a round trip; needs caching + batching</li>
+      <li><b>Ops surface</b> — backups, vacuum tuning, connection security, uptime</li>
+      <li><b>The async refactor still has to happen</b> — a sync call to a network DB is the worst of both worlds</li>
+    </ul>
+  </div>
+</div>
+<div class="callout good">
+  <div class="h">Why the async seam is the real hero</div>
+  <p>The Phase 0 seam (<code>db-async.js</code>, already shipped) is what makes Postgres' concurrency <em>usable</em> from Node. Without it, a networked query blocks the event loop and you've made freezes worse. With it, the same call site <code>await</code>s — Node stays responsive while N queries are in flight against the pool. <strong>One refactor serves both goals: kill freezes <em>and</em> enable concurrency.</strong></p>
+</div>
+<!-- ───────────────────────────── 04 ───────────────────────────── -->
+<h2 id="spark"><span class="n">04</span>The DGX Spark vision: one box, every subsystem</h2>
+<p class="lead">Today the stack is scattered: SQLite on local disk, Ollama on CPU, embeddings in-process, and the heavy reasoning (approval judge, coding agent, classifiers) farmed out to cloud Claude via Portkey. A DGX Spark collapses that into a single owned node.</p>
+<div class="num-strip">
+  <div class="stat"><div class="v">128 GB</div><div class="l">unified LPDDR5X<br>CPU+GPU share it</div></div>
+  <div class="stat"><div class="v">1 PFLOP</div><div class="l">FP4 AI perf<br>Blackwell GPU</div></div>
+  <div class="stat"><div class="v">20 cores</div><div class="l">Arm: 10× X925<br>+ 10× A725</div></div>
+  <div class="stat"><div class="v">200 GbE</div><div class="l">ConnectX-7<br>link 2 units → 405B</div></div>
+</div>
+<p>The unified-memory design is the interesting part for <em>us</em> specifically. Postgres' shared buffers, pgvector's HNSW index, and a local LLM's weights can all live in the same 128&nbsp;GB pool with no PCIe copy between "CPU memory" and "GPU memory." For a workload that is equal parts <b>transactional state</b> (Postgres), <b>vector recall</b> (pgvector/cuVS), and <b>inference</b> (embeddings + local judge models), that's an unusually good fit.</p>
+<div class="callout good">
+  <div class="h">The concrete tie-in that makes this non-hypothetical</div>
+  <p>EDB's GPU-accelerated Postgres vector extension (<b>PGPU</b>, open-sourced Dec 2025) accelerates <code>VectorChord</code> index builds on NVIDIA GPUs — and its supported-architecture list <strong>explicitly includes GB10</strong>, the exact superchip inside a DGX Spark. So "run Postgres with GPU-accelerated vector indexing on a Spark" is a supported configuration today, not a research project.</p>
+</div>
+<h3>What moves onto the box</h3>
+<table>
+  <thead><tr><th>Subsystem</th><th>Today</th><th>On a Spark</th></tr></thead>
+  <tbody>
+    <tr><td>Transactional state</td><td>SQLite file (local/Dropbox)</td><td>Postgres, served to all devices on the LAN/VPN</td></tr>
+    <tr><td>Vector recall (Wall-E brain)</td><td><code>sqlite-vec</code> int8, CPU, in-proc</td><td><code>pgvector</code>/VectorChord, GPU-built index (cuVS CAGRA/IVF-PQ)</td></tr>
+    <tr><td>Embeddings</td><td>CPU / small model</td><td>GPU batch embedding, much higher throughput</td></tr>
+    <tr><td>Local LLM (gemma/classifiers)</td><td>Ollama on CPU, ~87 tok/s</td><td>Blackwell GPU — large local models at interactive speed</td></tr>
+    <tr><td>Heavy reasoning (judge, coding agent)</td><td>Cloud Claude via Portkey</td><td>Hybrid: local for cheap/private turns, cloud for frontier — your call per route</td></tr>
+  </tbody>
+</table>
+<!-- ───────────────────────────── 05 ───────────────────────────── -->
+<h2 id="arch"><span class="n">05</span>Reference architecture</h2>
+<p class="lead">The same async data-access seam fronts everything. Devices and agents are just more clients of one pool; the GPU subsystems sit beside Postgres in shared memory.</p>
+<figure>
+<div class="svgwrap">
+<svg viewBox="0 0 920 470" role="img" aria-label="DGX Spark co-located architecture diagram">
+  <defs>
+    <marker id="arr" markerWidth="9" markerHeight="9" refX="7" refY="4.5" orient="auto">
+      <path d="M0,0 L9,4.5 L0,9 z" fill="#5a6b80"/>
+    </marker>
+    <linearGradient id="boxg" x1="0" y1="0" x2="0" y2="1">
+      <stop offset="0" stop-color="#141c28"/><stop offset="1" stop-color="#0e131b"/>
+    </linearGradient>
+  </defs>
+  <rect x="0" y="0" width="920" height="470" fill="none"/>
+  <!-- clients -->
+  <text x="40" y="34" fill="#9aa7b8" font-family="monospace" font-size="12" font-weight="600">CLIENTS</text>
+  <g font-family="-apple-system,sans-serif" font-size="13" fill="#e6edf3">
+    <rect x="40" y="46" width="150" height="44" rx="9" fill="url(#boxg)" stroke="#212a37"/><text x="115" y="73" text-anchor="middle">📱 Phone (PWA)</text>
+    <rect x="40" y="104" width="150" height="44" rx="9" fill="url(#boxg)" stroke="#212a37"/><text x="115" y="131" text-anchor="middle">💻 Laptop browser</text>
+    <rect x="40" y="162" width="150" height="44" rx="9" fill="url(#boxg)" stroke="#212a37"/><text x="115" y="189" text-anchor="middle">🤖 Autonomous agents</text>
+  </g>
+  <!-- app server -->
+  <rect x="280" y="70" width="180" height="120" rx="12" fill="url(#boxg)" stroke="#2c4a5e"/>
+  <text x="370" y="98" text-anchor="middle" fill="#5ec8ff" font-family="monospace" font-size="12" font-weight="700">CTM / WALL-E</text>
+  <text x="370" y="120" text-anchor="middle" fill="#e6edf3" font-family="sans-serif" font-size="13">Node app server</text>
+  <text x="370" y="142" text-anchor="middle" fill="#9aa7b8" font-family="sans-serif" font-size="12">SSE · PTY · queue</text>
+  <rect x="300" y="152" width="140" height="26" rx="6" fill="#0a1710" stroke="#26503a"/>
+  <text x="370" y="170" text-anchor="middle" fill="#7ee787" font-family="monospace" font-size="11">db-async seam (await)</text>
+  <!-- pooler -->
+  <rect x="510" y="98" width="96" height="64" rx="10" fill="url(#boxg)" stroke="#3a3050"/>
+  <text x="558" y="126" text-anchor="middle" fill="#9d7bff" font-family="monospace" font-size="11" font-weight="700">pgbouncer</text>
+  <text x="558" y="144" text-anchor="middle" fill="#9aa7b8" font-family="sans-serif" font-size="11">pool</text>
+  <!-- the spark box -->
+  <rect x="470" y="220" width="420" height="220" rx="14" fill="none" stroke="#3a2e5a" stroke-dasharray="6 5"/>
+  <text x="490" y="246" fill="#9d7bff" font-family="monospace" font-size="12" font-weight="700">DGX SPARK · 128 GB UNIFIED MEMORY</text>
+  <rect x="492" y="262" width="180" height="70" rx="10" fill="url(#boxg)" stroke="#2c3e6e"/>
+  <text x="582" y="288" text-anchor="middle" fill="#7aa2ff" font-family="monospace" font-size="12" font-weight="700">PostgreSQL</text>
+  <text x="582" y="308" text-anchor="middle" fill="#e6edf3" font-family="sans-serif" font-size="12">MVCC · JSONB</text>
+  <text x="582" y="324" text-anchor="middle" fill="#9aa7b8" font-family="sans-serif" font-size="11">tsvector + GIN (FTS)</text>
+  <rect x="690" y="262" width="180" height="70" rx="10" fill="url(#boxg)" stroke="#3a3050"/>
+  <text x="780" y="288" text-anchor="middle" fill="#9d7bff" font-family="monospace" font-size="12" font-weight="700">pgvector / VectorChord</text>
+  <text x="780" y="308" text-anchor="middle" fill="#e6edf3" font-family="sans-serif" font-size="12">halfvec · HNSW</text>
+  <text x="780" y="324" text-anchor="middle" fill="#9aa7b8" font-family="sans-serif" font-size="11">GPU index build (cuVS)</text>
+  <rect x="492" y="350" width="378" height="72" rx="10" fill="url(#boxg)" stroke="#3a4a2e"/>
+  <text x="681" y="376" text-anchor="middle" fill="#7ee787" font-family="monospace" font-size="12" font-weight="700">BLACKWELL GPU</text>
+  <text x="681" y="396" text-anchor="middle" fill="#e6edf3" font-family="sans-serif" font-size="12.5">Batch embeddings · local LLM (judge / classifiers / coding) · GPU ANN</text>
+  <text x="681" y="414" text-anchor="middle" fill="#9aa7b8" font-family="sans-serif" font-size="11">shares the same 128 GB — no PCIe copy between DB cache, index, and weights</text>
+  <!-- arrows -->
+  <g stroke="#5a6b80" stroke-width="1.6" fill="none" marker-end="url(#arr)">
+    <path d="M190 68 H276"/>
+    <path d="M190 126 H276"/>
+    <path d="M190 184 C 240 184, 250 150, 276 150"/>
+    <path d="M460 130 H506"/>
+    <path d="M558 162 V 240 H 560"/>
+    <path d="M672 297 H 686" />
+  </g>
+  <text x="232" y="60" fill="#9aa7b8" font-family="monospace" font-size="10">HTTPS / SSE</text>
+</svg>
+</div>
+<figcaption>One async seam, one pool, one box. Clients (incl. agents) are symmetric peers; GPU subsystems sit in the same memory as the DB.</figcaption>
+</figure>
+<!-- ───────────────────────────── 06 ───────────────────────────── -->
+<h2 id="gpu"><span class="n">06</span>What the GPU actually buys you</h2>
+<p class="lead">Be specific — a GPU doesn't speed up transactional reads. It helps exactly two of our subsystems, both of which are real bottlenecks at scale.</p>
+<div class="grid2">
+  <div class="card">
+    <h4><span class="dot" style="background:var(--gpu)"></span>Vector search &amp; index builds</h4>
+    <p><b>cuVS</b> (RAPIDS) runs CAGRA / IVF-PQ / IVF-flat ANN on the GPU. <b>VectorChord</b> indexes ~100M vectors in ~20&nbsp;min on CPU; GPU build via EDB PGPU cuts that further. For a growing brain, index <em>rebuild</em> time is the pain — this is where the GPU earns its place.</p>
+  </div>
+  <div class="card">
+    <h4><span class="dot" style="background:var(--accent2)"></span>Embeddings &amp; local inference</h4>
+    <p>Batch embedding generation is embarrassingly parallel — GPU throughput dwarfs CPU. And the approval judge / intent classifier / cheap coding turns could run on a <em>local</em> Blackwell-hosted model instead of round-tripping to cloud Claude, for privacy + zero marginal cost on the cheap turns.</p>
+  </div>
+</div>
+<div class="callout">
+  <div class="h">Where the GPU does nothing</div>
+  <p>The freeze-relevant path — thousands of tiny per-session metadata reads — is <strong>not</strong> GPU work. That's won by the async seam + a read cache, full stop. Don't let the shiny hardware distract from the fact that <em>Phase 0 alone fixes most of the freezes</em>. The GPU is for the vector + inference frontier, not for making CTM feel snappy.</p>
+</div>
+<!-- ───────────────────────────── 07 ───────────────────────────── -->
+<h2 id="sizing"><span class="n">07</span>Capacity &amp; sizing — rough numbers</h2>
+<p class="lead">Order-of-magnitude only, to calibrate ambition. The honest takeaway: today's load doesn't need a Spark; a Spark only makes sense if local inference becomes a first-class part of the product.</p>
+<table>
+  <thead><tr><th>Workload</th><th>Today's scale</th><th>Fits in…</th></tr></thead>
+  <tbody>
+    <tr><td>CTM transactional state</td><td>~35 tables, sessions+messages</td><td class="yes">Trivially in 128 GB RAM; would fit a Raspberry Pi's Postgres, honestly</td></tr>
+    <tr><td>Wall-E brain</td><td>~1–2.6 GB (int8 FTS-optimized)</td><td class="yes">Entirely in shared buffers; halfvec keeps it small</td></tr>
+    <tr><td>Embedding index</td><td>brain-scale vectors</td><td class="yes">In-memory HNSW; GPU build is a latency win, not a capacity need</td></tr>
+    <tr><td>Local inference</td><td>gemma-class today</td><td class="meh">This is the <em>only</em> thing that wants the Blackwell GPU — and only if you move judge/classifier/coding turns local</td></tr>
+  </tbody>
+</table>
+<div class="callout warn">
+  <div class="h">Sizing reality check</div>
+  <p>The database half of this never needed a supercomputer — Postgres on a $5/mo VM or a Mac mini handles CTM+Wall-E's state for one user with room to spare. <strong>The Spark is justified by the inference half, not the data half.</strong> If you're not moving meaningful LLM work local, a hosted Postgres (Fly/Neon/Supabase) from the original plan is the rational stop point.</p>
+</div>
+<!-- ───────────────────────────── 08 ───────────────────────────── -->
+<h2 id="phasing"><span class="n">08</span>How this extends the Phase 0–5 plan</h2>
+<p class="lead">Nothing here replaces the existing spec — it adds an optional fork at the end. The first five phases are unchanged and remain independently valuable.</p>
+<table>
+  <thead><tr><th>Phase</th><th>From the original plan</th><th>Concurrency / Spark overlay</th></tr></thead>
+  <tbody>
+    <tr><td><b>0</b> <span class="tag now">shipped</span></td><td>Async data-access seam on SQLite</td><td>This is the prerequisite for <em>all</em> concurrency. Already on <code>feat/db-async-seam</code>.</td></tr>
+    <tr><td><b>1–2</b></td><td>Schema port + FTS→tsvector, sqlite-vec→pgvector</td><td>Choose <code>pgvector</code> <em>or</em> <code>VectorChord</code> at this step — VectorChord if GPU index builds are on the table.</td></tr>
+    <tr><td><b>3–4</b></td><td>ETL + parity tests, cutover, retire SQLite machinery</td><td>Unchanged. Pooling (pgbouncer) is added here for multi-client readiness.</td></tr>
+    <tr><td><b>5</b></td><td>Enable remote/multi-device + read cache + auth</td><td>This is where concurrency becomes <em>real</em>. Gate on p50/p99 latency parity.</td></tr>
+    <tr><td><b>6</b> <span class="tag far">new, optional</span></td><td>—</td><td><b>Co-locate on owned compute (Spark).</b> Move GPU embedding + local inference onto the box; hybrid-route cheap/private turns local, frontier turns to cloud.</td></tr>
+  </tbody>
+</table>
+<!-- ───────────────────────────── 09 ───────────────────────────── -->
+<h2 id="risks"><span class="n">09</span>Risks &amp; honest caveats</h2>
+<div class="grid2">
+  <div class="card"><h4><span class="dot" style="background:var(--bad)"></span>Single point of failure</h4><p>Co-locating everything on one box means one box's downtime takes the whole stack. A file-based SQLite that travels with the app has a real resilience advantage for a solo user.</p></div>
+  <div class="card"><h4><span class="dot" style="background:var(--bad)"></span>Arm64 + DGX OS quirks</h4><p>Spark is Arm + a custom Ubuntu (DGX OS). <code>better-sqlite3</code>/native-module ABI lessons apply doubly; pin Node, verify pgvector/VectorChord/cuVS builds for Arm + GB10.</p></div>
+  <div class="card"><h4><span class="dot" style="background:var(--warn)"></span>Latency can still regress feel</h4><p>Networked DB + agents hammering it = lag unless the read cache + batching land. This is the make-or-break from the original plan, unchanged.</p></div>
+  <div class="card"><h4><span class="dot" style="background:var(--warn)"></span>Overkill risk</h4><p>For one user with cloud LLM calls, a Spark is expensive idle silicon. Don't buy hardware to solve a software (async) problem.</p></div>
+  <div class="card"><h4><span class="dot" style="background:var(--warn)"></span>Ops surface grows</h4><p>Postgres needs backups, vacuum/autovacuum tuning, connection security. A GPU node adds driver/CUDA lifecycle on top.</p></div>
+  <div class="card"><h4><span class="dot" style="background:var(--accent2)"></span>But the seam is free insurance</h4><p>Phase 0 is done and reversible. Every later decision — hosted PG, Spark, or stay on SQLite — is now <em>open</em> rather than foreclosed. That optionality is the real win today.</p></div>
+</div>
+<!-- ───────────────────────────── 10 ───────────────────────────── -->
+<h2 id="verdict"><span class="n">10</span>Decision matrix: when is this worth it?</h2>
+<table>
+  <thead><tr><th>Your situation</th><th>Right move</th><th>Why</th></tr></thead>
+  <tbody>
+    <tr><td>Solo user, freezes are the only pain</td><td><b>Stop at Phase 0</b> (+ read cache)</td><td>The async seam captures most freeze relief on SQLite. No engine change needed.</td></tr>
+    <tr><td>Want phone + laptop on the same brain</td><td><b>Phases 1–5, hosted Postgres</b></td><td>Multi-device forces a server DB; Fly/Neon/Supabase is the low-ops path.</td></tr>
+    <tr><td>Many concurrent agents writing state</td><td><b>Phases 1–5 + pooling</b></td><td>MVCC + pgbouncer is exactly the model genuine write concurrency needs.</td></tr>
+    <tr><td>Heavy local inference + privacy + always-on, on owned hardware</td><td><b>Phase 6 — the Spark</b></td><td>The <em>only</em> scenario where co-location pays for itself. Unified memory + GB10 GPU vector + local LLM is a genuinely strong fit.</td></tr>
+    <tr><td>Just exploring</td><td><b>Keep the seam, watch VectorChord/cuVS</b></td><td>You've bought optionality cheaply. Decide when a real driver (a second device, or local-inference ambition) appears.</td></tr>
+  </tbody>
+</table>
+<div class="callout good">
+  <div class="h">Bottom line</div>
+  <p>The Spark idea is <strong>not a fantasy</strong> — the hardware and the GPU-Postgres software (EDB PGPU on GB10, VectorChord, cuVS) line up unusually well for a workload that's one-third state, one-third vectors, one-third inference. But it answers a question we haven't yet asked the product: <em>do we want meaningful LLM inference to run on hardware we own?</em> If yes, this is the destination. If no, hosted Postgres is the honest stopping point, and Phase 0 already bought us most of the freeze relief regardless.</p>
+</div>
+<hr>
+<footer>
+  <p class="src"><b>Sources</b><br>
+  · <a href="https://www.nvidia.com/en-us/products/workstations/dgx-spark/">NVIDIA DGX Spark — product page</a><br>
+  · <a href="https://docs.nvidia.com/dgx/dgx-spark/hardware.html">DGX Spark User Guide — Hardware Overview</a><br>
+  · <a href="https://www.microcenter.com/product/699008/nvidia-dgx-spark">Micro Center — DGX Spark specs (GB10, 20-core Arm, 128 GB LPDDR5X, 4 TB)</a><br>
+  · <a href="https://www.enterprisedb.com/docs/edb-postgres-ai/latest/ai-factory/pgpu/">EDB Postgres AI — PGPU GPU-accelerated vector index build (lists GB10 support)</a><br>
+  · <a href="https://github.com/supervc-stack/VectorChord">VectorChord — scalable disk-friendly vector search in Postgres (successor to pgvecto.rs)</a><br>
+  · <a href="https://rapids.ai/cuvs/">RAPIDS cuVS — GPU ANN (CAGRA, IVF-PQ, IVF-flat)</a><br>
+  · <a href="https://github.com/pgvector/pgvector">pgvector — halfvec, HNSW</a></p>
+  <p style="margin-top:18px;color:#6b7888">CTM + Wall-E architecture discussion · companion to the Postgres migration spec (Phases 0–5) · 2026-06-28 · exploratory, not a commitment.</p>
+</footer>
+</div>
+</body>
+</html>

package/template/claude-task-manager/docs/prompt-manager-redesign-proposal.html CHANGED Viewed

@@ -471,15 +471,17 @@
   <section id="editor">
     <div class="sec-head"><span class="sec-num">04</span><h2>Editor — author what a prompt really is</h2></div>
     <p class="sec-sub">
-      Phase 2 flagship. Prompts here are templated markdown sent to coding agents. The editor should treat
-      them that way: highlight markdown structure and <code>{{variables}}</code>, preview the rendered result,
-      and show a live token meter — instead of a styled rich-text box.
+      Phase 2 flagship. Prompts here are templated markdown sent to coding agents — so the editor ships
+      <b>both</b> a rich WYSIWYG mode <b>(default)</b> and a Markdown mode, with a one-click switch in the
+      toolbar. Either mode highlights <code>{{variables}}</code>, offers a live preview, and shows a live
+      token meter; switching is lossless (content round-trips HTML&nbsp;↔&nbsp;markdown).
     </p>
     <div class="mock">
       <div class="mock-caption"><span class="dot r"></span><span class="dot y"></span><span class="dot g"></span><span class="url">localhost:3456/#prompts → Deep code review</span></div>
       <div class="ed-toolbar">
-        <span class="seg"><b class="on">Edit</b><b>Preview</b><b>Split</b></span>
+        <span class="seg" title="Editor mode — WYSIWYG is the default"><b>✎ Rich</b><b class="on">&lt;/&gt; Markdown</b></span>
+        <span class="seg"><b>Edit</b><b>Preview</b><b class="on">Split</b></span>
         <span class="tb">{{ }}</span>
         <span class="tb">/ snippet</span>
         <span class="tb">@ file</span>
@@ -520,33 +522,32 @@
       <div><b>Prior art:</b> A live in-editor <b>token counter</b> is documented mainly in Google AI Studio — a genuine differentiator. The Anthropic Console "Variables window" separates template text from inputs; Claude Code's <code>!`cmd`</code> and <code>@file</code> inject live repo context. Both map directly onto what CTM prompts need.</div>
     </div>
-    <h3 style="font-size:18px; margin:34px 0 4px;">Two editor directions</h3>
+    <h3 style="font-size:18px; margin:34px 0 4px;">Both modes, one switch</h3>
     <div class="alt-grid">
       <div class="alt-card rec">
-        <h4>Option A — Markdown / code editor <span class="rectag">Recommended</span></h4>
-        <div class="sub">CodeMirror-style, built for markdown prompts.</div>
+        <h4>Rich · WYSIWYG <span class="rectag">Default</span></h4>
+        <div class="sub">The familiar editor, upgraded.</div>
         <ul>
-          <li>Markdown + <code>{{variable}}</code> + <code>!`cmd`</code>/<code>@file</code> syntax highlighting</li>
-          <li>Edit / Preview / Split modes; live preview pane</li>
-          <li>Live token + character meter against the model limit</li>
-          <li><code>/</code> snippet insert (reuse the existing slash picker)</li>
-          <li>Image paste &amp; annotation retained as an add-on layer</li>
-          <li class="con">Larger build: introduce CodeMirror; migrate HTML content → markdown</li>
+          <li>Keeps <code>contenteditable</code> formatting + first-class image annotation</li>
+          <li><code>{{variables}}</code> render as inline chips</li>
+          <li>Live token/char meter + a preview toggle</li>
+          <li><code>/</code> snippet &amp; <code>@</code> file insert</li>
+          <li>Zero learning curve — what most prompts need</li>
         </ul>
       </div>
-      <div class="alt-card">
-        <h4>Option B — Enhanced WYSIWYG</h4>
-        <div class="sub">Keep <code>contenteditable</code>, add the missing bits.</div>
+      <div class="alt-card rec">
+        <h4>Markdown · source <span class="rectag">One click away</span></h4>
+        <div class="sub">CodeMirror-style, for power authoring.</div>
         <ul>
-          <li>Render <code>{{variables}}</code> as inline chips</li>
-          <li>Add a token/char counter + a preview toggle</li>
-          <li>Slash-snippet insert; keep image annotation first-class</li>
-          <li>Lower risk; no content-format migration</li>
-          <li class="con">No real syntax highlighting; <code>execCommand</code> quirks remain</li>
+          <li>Markdown + <code>{{variable}}</code> + <code>!`cmd`</code>/<code>@file</code> highlighting</li>
+          <li>Edit / Preview / Split sub-modes; live preview pane</li>
+          <li>Same live token meter; same <code>/</code> &amp; <code>@</code> inserts</li>
+          <li>Exact control over whitespace &amp; structure</li>
+          <li>Image annotation still available via paste</li>
         </ul>
       </div>
     </div>
-    <p class="sec-sub" style="margin-top:18px;"><b>Recommendation:</b> Option A for coding prompts — markdown is the native format and highlighting/preview pay off daily. Keep B as the low-risk fallback if the markdown migration proves heavier than expected; image annotation survives either way.</p>
+    <p class="sec-sub" style="margin-top:18px;"><b>How it works:</b> the toolbar mode switch (<code>✎&nbsp;Rich&nbsp;|&nbsp;&lt;/&gt;&nbsp;Markdown</code>) flips between them; <b>WYSIWYG is the default</b>. Switching is <b>lossless</b> — content round-trips through the existing <code>htmlToMarkdown</code> converter (<code class="mono">prompts.js</code>) and a markdown→HTML renderer, and the chosen mode is remembered per user. No data migration: prompts keep their stored HTML, markdown is derived on demand.</p>
   </section>
   <!-- ===================== REUSE ===================== -->
@@ -624,7 +625,7 @@
       </div>
       <div class="phase">
         <div class="pn">Phase 2<small>Editor</small></div>
-        <div class="pbody"><h4>Markdown / code editor</h4><p>Introduce a CodeMirror-style editor: markdown + <code>{{var}}</code> highlighting, Edit/Preview/Split, live token meter, <code>/</code> snippets. Keep image annotation as an add-on. Migrate stored HTML → markdown.</p></div>
+        <div class="pbody"><h4>Dual-mode editor</h4><p>Ship <b>Rich (WYSIWYG, default)</b> + <b>Markdown</b> with a lossless toolbar switch. Markdown mode adds <code>{{var}}</code> highlighting, Edit/Preview/Split, live token meter, <code>/</code> snippets. Image annotation kept in both. No content migration — markdown derived via <code>htmlToMarkdown</code>.</p></div>
         <span class="risk med">Med</span>
       </div>
       <div class="phase">