Add implementation plan for goinitus-web rewrite

[claude]

Requested by Samuel Venzi · Slack thread

Summary

Adds IMPLEMENTATION_PLAN.md, a concrete plan for rebuilding goinitus-web as a full feature-parity reimplementation of legacy go-initus (develop branch), speaking the unchanged ccapi-go REST contract. It builds directly on ARCHITECTURE.md and cross-checks it against the actual go-initus/ccapi-go source rather than taking it at face value (see Appendix A for two real corrections found: a missing ~-prefixed transient/private transaction-argument convention, and inaccurate createAsset/updateAsset request-body shapes).

Structure of the document:

• Scope — full parity with legacy go-initus, same REST contract, no new features except opportunistic tech-debt fixes called out explicitly.
• Target stack — concrete recommendations (Vite, MUI v6, Zustand, React Hook Form + Zod, Axios 1.x, React Router 6) with one-line justifications each, explicitly framed as needing Samuel's confirmation, not a done deal.
• Feature parity checklist — a table per domain (Bootstrap/schema loading, Asset CRUD, Dynamic asset-type management, Custom transactions, Dashboard, Auth) mapping every legacy screen/endpoint to what the rewrite must cover, with tech-debt items marked as either bundled in opportunistically or explicitly deferred.
• Phased roadmap — Phase 0 (scaffold + API client) through Phase 5 (auth hardening + polish), each phase scoped to specific legacy screens/endpoints.
• Out of scope / open questions — see below.
• Appendix A — corrections/additions found while cross-checking ARCHITECTURE.md against source.

Open questions for Samuel

1. State management: Zustand (recommended) vs. staying on MobX 6.
2. Dashboard ambition: byte-for-byte parity with today's hardcoded panels, or make it actually config-driven (a real feature addition, not default scope)?
3. OAuthCredentialInput: react-google-login's underlying Google API was shut down in 2023 — reimplement against a working OAuth library for real parity, or keep the input type/wire-format only?
4. XYTCredentialInput: depends on an external "fingerprint server" that appears to be stored but not actually wired into a request path — confirm it's still needed before investing effort.
5. Auth model: ccapi-go's Basic Auth is a single shared AUTH_USER/AUTH_PASS pair gated by ENABLE_AUTH, not per-user accounts — any "hardening" is client-side only unless the backend changes; confirm that's acceptable.
6. Deployment target: same Docker (Node build → Nginx serve, cookie-injected base URL) shape, or something else now that we're rebuilding anyway?
7. Private-collection query-param asymmetry between readAsset (?collections=<name>) and createAsset/updateAsset (?@collections=<base64 array>) is a ccapi-go contract quirk, not fixable from the frontend — flagging so it isn't mistaken for a bug, no action expected unless Samuel wants to raise it with the backend team separately.
8. getDataTypes failure handling: legacy silently degrades and continues booting — keep that behavior or block boot on failure?

[samuelvenzi]

@claude We don't have to keep the same stack. We can modernize that too.

[claude]

Updated per this feedback: the Target Stack section now states the modern picks (Vite, React 19, MUI v6, Zustand, Zod, RHF, Axios) as confirmed rather than pending sign-off, and Open Question #1 (Zustand vs. MobX) is removed since it's resolved.

To be explicit: this is a frontend tooling/library decision only. The ccapi-go REST contract (/api/query/* and /api/invoke/*) is unaffected and stays exactly as-is regardless of frontend stack.

Pushed to docs/implementation-plan (f344193).