cockpit: unified ClassView card — OSINT node detail popup + generic /api/card.html route

[AdaWorldAPI]

First consumer proof of the unified ClassView render (companion to AdaWorldAPI/lance-graph#650, which must merge first — the Dockerfile clones lance-graph @ main HEAD): click a node in the OSINT cockpit → a server-rendered askama fragment fills a detail popup from the node's ClassView fieldmask, values read from the 12-byte content-blind facet. Two routes, one code path — resolve → carve → emit, routes as skins.

Routes

Route	Role
GET /api/osint/card.html?name=&fragment=1 (+ existing class/mask)	the OSINT app skin — name→V3-index lookup, slot rule (GUID1→system card 0x0700, GUID2→person card 0x0701 for persons)
GET /api/card.html?guid=&class=&mask=&fragment=	the generic route — any 16-byte key renders with zero storage: the guid is the payload ("the key prerenders nodes with zero value decode"). Unknown concepts fall to the generic facet dump (b0..b11), never a 404
GET /api/osint/card, /api/osint/card.html (no new params)	byte-identical to before (regression-tested)

The R1 decision (recon finding, ratified)

The live gotham scene's GUID bytes 4..16 are HHTL routing tiers, not facets — the true 12-byte facet GUIDs (+ GUID2 for persons) live in data/osint-v3/ (611 nodes, unserved until now). Resolution: keep the live scene; a server-side name → (guid1, guid2, is_person) index over osint_v3_nodes.json resolves clicked labels; the ~309 unmatched nodes fall back to the schema card — the zero-fallback ladder behaving as designed. Reconciling gotham's 11-byte tenant order instead was rejected (it would mint a second field-order truth); the durable fix is re-baking gotham with V3 facet GUIDs (follow-up, data work).

⚠️ Operator attention: V3 bake byte order

Decoding the bake against the declared field order lands only 16/611 (guid1) / 52/133 (guid2) values in-vocabulary; swapping each tier's hi/lo byte pair yields 609/611 and 133/133 — near-proof the bake stores u16 tiers LE (lo,hi) while OSINT_SYSTEM_FIELDS declares (hi,lo) reading order. Per the don't-guess rule this PR does not reorder bytes — OSINT_DECODE is mechanical and will show low hit rates until the field-order declaration or the bake is corrected (one deliberate follow-up, either side). guid2/McClelland is left undecoded entirely (mcclelland_vocab is a plain array; 0- vs 1-indexing would be a guess).

React popup

NodeDetailPopup in OsintGraph.tsx — rides the existing click handler (keeps reasonFrom untouched), fetches the fragment, injects it schema-blind (dangerouslySetInnerHTML + popup-scoped CSS in the cockpit palette, ReasonBox pattern). New node classes get working popups with zero cockpit rebuild. Empty-space clicks close it. Also adds the missing /osint.soa vite dev-proxy line.

Verification (honest status)

• cockpit-server unit tests: 4 → 10 passing; clippy -D warnings clean; askama templates compile-checked
• Caveat: cargo check -p cockpit-server cannot complete in the dev sandbox — deno_core → v8 needs a static-lib download the egress policy 403s (pre-existing; any edit to this crate hits it). Verification ran in an isolated harness against the real lance-graph-contract path dep + real templates + an axum::Router wiring test matching main.rs. The Railway build (open egress) is the true compile gate for this crate.
• cd cockpit && npm run build (tsc + vite): clean
• Plan + wave log: claude-notes/plans/2026-07-06-classview-unified-render.md

🤖 Generated with Claude Code

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@AdaWorldAPI, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 206f8dfb-2c4e-458d-ac7a-99eb3cbefbd6

📥 Commits

Reviewing files that changed from the base of the PR and between 33de0af and 04d8223.

📒 Files selected for processing (1)

• claude-notes/plans/2026-07-06-classview-unified-render.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}