You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .beads/issues.jsonl
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,4 @@
1
+
{"id":"warpgrid-5fj","title":"Serve warpgrid.dev via WarpGrid Cloud (dogfooding)","description":"Migrate warpgrid.dev from include_str\\!() in warpd to a standalone website deployed as a WarpGrid Wasm component. Currently the landing page is baked into the warpd binary, which: (1) couples frontend to backend releases, (2) bloats the customer-downloadable binary, (3) requires 3-min Rust rebuilds for page edits, (4) is dishonest — we claim WarpGrid is great but don't use it ourselves. The website repo (warpgrid-website) gets compiled to Wasm via warp pack and deployed via warp deploy. The site itself becomes a showcase: 'This page runs on WarpGrid.' Dependencies: warpgrid-website repo must be created first.","status":"open","priority":1,"issue_type":"feature","owner":"janos@dot.industries","created_at":"2026-03-17T18:23:13.222459+01:00","created_by":"János Veres","updated_at":"2026-03-17T18:23:13.222459+01:00"}
1
2
{"id":"warpgrid-agm","title":"WarpGrid SDK — Fork Engineering Implementation","description":"Curated, tested distribution of WebAssembly toolchain components that enables WarpGrid (a Wasm-native cluster orchestrator) to run real-world backend services. Pushes WASI workload compatibility from ~25-35% to 60-70% through 6 coordinated engineering domains:\n\n1. Wasmtime host functions (shim layer foundation)\n2. wasi-libc patches (socket/filesystem compat)\n3. TinyGo WASI overlay (Go workload support)\n4. ComponentizeJS extensions (TypeScript/Node.js support)\n5. WASI 0.3 async pre-integration (async I/O)\n6. Bun WASI runtime (Bun/TypeScript support)\n\n85 user stories across 7 sections with explicit dependency chains.\n\nQuality Gates (per domain):\n- Rust: cargo check \u0026\u0026 cargo test \u0026\u0026 cargo clippy -- -D warnings\n- C/libc: make + scripts/test-libc.sh\n- Go: tinygo build -target=wasip2 + go test ./...\n- TypeScript: npm run typecheck + npm test\n- Bun: bun run typecheck + bun test\n- All: TDD (tests written BEFORE implementation)","status":"open","priority":1,"issue_type":"epic","owner":"janos@dot.industries","created_at":"2026-02-22T11:47:49.620679+01:00","created_by":"János Veres","updated_at":"2026-02-22T11:47:49.620679+01:00","external_ref":"prd:./tasks/prd-warpgrid-sdk.md"}
2
3
{"id":"warpgrid-agm.1","title":"US-101: Scaffold the warpgrid-host crate with dependencies","description":"Milestone: M1.1 | Depends on: none\n\nAs a SDK developer, I want a properly structured warpgrid-host crate with all required dependencies so that I have a compilable foundation for implementing host function shims.\n\n## Acceptance Criteria\n- [ ] crates/warpgrid-host/ directory exists with Cargo.toml and src/lib.rs\n- [ ] Cargo.toml declares dependencies on wasmtime, wasmtime-wasi, tokio (with rt-multi-thread, macros, net, time features), tracing, and anyhow\n- [ ] Dev-dependencies include tokio (with test-util), tracing-subscriber, and wasmtime (with component-model feature)\n- [ ] src/lib.rs contains public crate-level module structure (empty modules for filesystem, dns, signals, db_proxy, threading, config, engine)\n- [ ] cargo check -p warpgrid-host passes with zero errors\n\n## Quality Gates\n- [ ] cargo check passes\n- [ ] cargo test passes\n- [ ] cargo clippy -- -D warnings passes\n- [ ] Tests written before implementation (TDD)","status":"closed","priority":1,"issue_type":"task","owner":"janos@dot.industries","created_at":"2026-02-22T11:50:04.860934+01:00","created_by":"János Veres","updated_at":"2026-02-22T12:41:08.207798+01:00","closed_at":"2026-02-22T12:41:08.207798+01:00","close_reason":"Scaffolded crate with all modules, workspace integration, and quality gates passing","dependencies":[{"issue_id":"warpgrid-agm.1","depends_on_id":"warpgrid-agm","type":"parent-child","created_at":"2026-02-22T11:50:04.862488+01:00","created_by":"János Veres"}]}
3
4
{"id":"warpgrid-agm.10","title":"US-110: Signal handling integration tests","description":"Milestone: M1.4 | Depends on: US-109\n\nAs a SDK developer, I want integration tests proving Wasm modules can register for and receive signals.\n\n## Acceptance Criteria\n- [ ] Test: Wasm component registers for terminate, host delivers it, poll-signal returns it\n- [ ] Test: poll-signal on empty queue returns None\n- [ ] Test: queue bounding — 20 signals delivered, only 16 most recent retrievable\n- [ ] Test: signal filtering — register hangup only, deliver terminate, poll returns None\n- [ ] All integration tests against real Wasmtime engine instance\n\n## Quality Gates\n- [ ] cargo check passes\n- [ ] cargo test passes\n- [ ] cargo clippy -- -D warnings passes\n- [ ] Tests written before implementation (TDD)","status":"in_progress","priority":2,"issue_type":"task","owner":"janos@dot.industries","created_at":"2026-02-22T11:51:12.007536+01:00","created_by":"János Veres","updated_at":"2026-02-24T04:31:30.971434+01:00","dependencies":[{"issue_id":"warpgrid-agm.10","depends_on_id":"warpgrid-agm","type":"parent-child","created_at":"2026-02-22T11:51:12.008255+01:00","created_by":"János Veres"},{"issue_id":"warpgrid-agm.10","depends_on_id":"warpgrid-agm.9","type":"blocks","created_at":"2026-02-22T12:08:17.148497+01:00","created_by":"János Veres"}]}
0 commit comments