alee/relicario
1
0
Fork 0
Code Issues Pull Requests 6 Actions Packages Projects Releases Wiki Activity

docs: record v0.9.0 org-write spike decision + device-key prereq (PM)

Browse Source 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013Hc6Rvdz3DxLucqNtPE2iP
This commit is contained in:
adlee-was-taken
2026-06-26 00:39:54 -04:00
parent 79284979c1
commit 13512ed9bf
2 changed files with 26 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
STATUS.md
View File

@@ -6,7 +6,22 @@
**Last release tagged:** v0.8.1 (`2fa4d68`, 2026-06-20) — org item-type parity + collection-scoped attachments, on top of v0.8.0 enterprise org vault. (v0.7.0 extension restructure; v0.6.0 rolled up Phase 2B / v0.5.1 / 1C-γ / Plan B / management-surfaces / doc-structure.)
**Cutting now:** **v0.8.2 — extension vault-creation fix.** Binary-safe `chrome.runtime.sendMessage` transport (`message-binary.ts`) + carrier-image magic-byte guard + setup-wizard router allowlist + vault-tab drawer/lock layout. Extension-only; core/cli/wasm bumped 0.8.1→0.8.2 for tag consistency, `relicario-server` stays 0.1.1. Merged to main `938174b`; `release: v0.8.2` doc/tag commit pending.
**Next track:** **v0.9.0 — extension org GUI + pluggable second factor.** 2 specs + 5 plans committed (`74cee8a`), 0/140 tasks executed — ready for a `mode:"multi"` kickoff.
**In flight:** **v0.9.0 — extension org GUI + pluggable second factor.** Multi-agent lift kicked off 2026-06-25 (5 streams, relay-coordinated). **Org-write scope decision (2026-06-25):** the signed-commit spike proved the signature mechanism (GO), but research found Gitea has **no write Git Data API at any version** (1.26.4 latest; none on roadmap; Contents API can't carry a caller signature) — so org-write ships via **native `git-receive-pack` packfile push (isomorphic-git in the SW), a single universal write path for both Gitea + GitHub**. User chose **build-now in v0.9.0** (not defer). Details in the v0.9.0 lift block below.
## v0.9.0 lift — in progress (kicked off 2026-06-25)
Two-track multi-agent lift (5 streams, relay-coordinated; PM + Dev-A..E):
- **Org track (merge order A→B→C):** Dev-A org SW+WASM foundation, Dev-B org read UI, Dev-C org write.
- **Keyfile track (merge order D→E):** Dev-D keyfile core/cli/wasm, Dev-E keyfile extension + positioning pivot. Independent of the org track.
**Org-write transport decision (2026-06-25) — recorded per the org-GUI spec's spike gate:**
- Spike (Dev-C, `426b82a`; doc `docs/superpowers/spikes/2026-06-20-org-signed-commit-spike.md`): **signature mechanism is GO** — a SW-built SSHSIG commit (raw `sign_for_git` + manual SSHSIG framing, no new WASM export) passes both `git verify-commit` and `relicario-server verify-org-commit`, incl. item+manifest dual-write + grant/slug authz. Hook matches the **signing-key fingerprint** → `members[].ed25519_pubkey` (committer text free-form, not checked).
- **Transport:** Gitea has **no write Git Data API at any version** (research vs 1.26.4 latest / roadmap / `repo_file.go`; Contents API can't carry a caller signature). The route is **native `git-receive-pack` packfile push via isomorphic-git** in the SW — host-agnostic, works at any Gitea version, preserves the SSHSIG byte-for-byte; extension `host_permissions` avoids the CORS proxy. ~68KB gzip dep.
- **Decision (user):** **build now in v0.9.0** as the **single universal write path for both Gitea + GitHub** (GitHub-only Git Data API approach retired). Plan C re-scoped. **Mini-spike PROVEN GO (2026-06-25):** isomorphic-git `commit({onSign})` embeds the SSHSIG (exact-payload, zero canonicalization risk) and passes `verify-commit` + the **real org pre-receive hook over `git-receive-pack`** — owner-signed accepted, non-member rejected; works at any Gitea version + GitHub. Now building the universal `commitSigned` (A/B-independent); org write handlers + UI held until A+B merge; **`/security-review` mandatory** on the push path before merge. Residual: 1 live-creds push (transport-only, confirm at integration).
**Tracked follow-up bug (out of v0.9.0 scope unless trivial):** `extension/src/service-worker/gitea.ts` `putBlob` large-blob fallback calls nonexistent Gitea `/git` write endpoints → attachments over `BLOB_THRESHOLD_BYTES` 404 on a Gitea host (pre-existing ~v0.8.2). Found during the spike.
**Org foundation scope addition (2026-06-26):** Dev-A discovered the extension never persists the device ed25519 private key — `DEVICE_STATE` (WASM `device.rs`) is in-memory only, wiped on every SW restart; `chrome.storage.local` stores only `vaultConfig`/`imageBase64`/`device_name`. The org-GUI spec's assumption of `chrome.storage.local.device_private_key` was wrong; the device-auth key lifecycle was never completed (the extension never used `sign_for_git`). Since `org_unwrap_key` (read) **and** `sign_for_git` (Dev-C write) both need it, A is building **device-key persist+restore (Variant Y)** as a foundation prereq (Task 4.5): encrypt the device key under the personal master key at register, restore into `DEVICE_STATE` at unlock (decrypt **inside** WASM — the private key never crosses to JS), and refactor `org_unwrap_key(keys_blob)` to read `DEVICE_STATE`. Expands the org track scope/timeline; keyfile track (D/E) unaffected.
## What landed on main since the v0.5.0 version bump