oy/openyield
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 42 Wiki Activity

docs(P00): clarify — v0.6 decisions D-066..D-073

Browse Source 
User-validated stack: Go html/template + HTMX, Go mock API server,
new web/ dir, all 5 screens. Lexicon firewall extended to web/.
Bread-scale source of truth = x/bread/types code constants.

---ci---
project: oy
phase: 0
milestone: v0.6
status: clarify
---/ci---
This commit is contained in:
cloudinit-bot
2026-08-18 11:54:59 +00:00
parent 68298d81b3
commit 4876c49aa0
2 changed files with 18 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.ciagent/CHECKPOINT.json
+2 -2
View File
@@ -1,12 +1,12 @@
{
"phase": 0,
"stage": "specify",
"stage": "clarify",
"milestone": "v0.6",
"milestone_type": "feature",
"tag_base": "v0.5.x",
"phase_role": "pre_execution",
"project": "oy",
"attempts": 0,
"updated_at": "2026-08-18T11:30:00Z",
"updated_at": "2026-08-18T11:35:00Z",
"milestone_complete": false
}
.ciagent/oy/PROJECT.md
+15
View File
@@ -292,3 +292,18 @@ Auto-decided defaults logged per clarify workflow Step 4 (full autonomy → acce
| D-059 | **IBC packet scope = the 5 L2 chains already in the v0.2 skeleton** (Polygon, Base, Arbitrum, Optimism, Solana per REQ-009/`x/satellite`). v0.5 `x/bridge` handlers implement IBC packet recv/ack for these 5 chains' `BridgeStatus` transitions. No new L2 chains in v0.5. Solana IBC uses the wormhole-style bridge adapter (already stubbed in `x/bridge` per D-021). | The 5 L2 chains are the locked-const set (REQ-009). Adding new chains is a Year-4 concern. Solana IBC was a v0.1 deferred item (D-021) now promoted. | 0.82 | [add 3+ new L2 chains (Year 4); defer Solana IBC again (stalls)] |
| D-060 | **Council governance shape (AUDIT §193 P1-1)**: add `Proposal` and `VoteOption` enum types to `x/council/types` (currently absent per AUDIT). `ProposalKind` enum = {Stand, Guild, Mesh, MissionLockAmendment-Rejected} (Mission Lock non-amendable → the enum value exists but the handler rejects it; documents the non-amendability in code). `VoteOption` enum = {Yes, No, Abstain, Veto} (Veto = Watcher-only, quorum rule). SignalKind stays at 4 sources (P1-2 defensible per AUDIT; expansion deferred to v0.6+ governance vote). Mission Lock const firewall (G-003) intact. | AUDIT P1-1 flagged the absence as a divergence. Adding the enums is `feat:` (deferred from v0.4 by D-001). P1-2 (SignalKind 4→5) is a locked-const change rejected by the audit rationale, so it stays at 4. | 0.82 | [add SignalKind 5th source (locked-const change, rejected); defer Proposal/VoteOption again (stalls)] |
| D-061 | **No IDEATE stage in v0.5** (no `--ideate` flag this run). The feature scope was pre-seeded from PROJECT.md v0.4 out-of-scope + AUDIT §193 P1-1 + D-050 and ratified at CLARIFY. The D-001 refinement-only filter does NOT apply (v0.5 is a feature milestone, not NFR). | run.md §IDEATE is conditional on `--ideate`. This invocation has no `--ideate`. | 1.00 | [run IDEATE anyway] |
## Clarification Decisions (Phase 0 v0.6 — CLARIFY, autonomy=full)
Auto-decided defaults logged per clarify workflow Step 4 (full autonomy → accept defaults, log decisions). `--ideate` flag IS present this run; v0.6 is the project's first UI milestone. The D-001 refinement-only filter does NOT apply (v0.6 is a feature milestone). User-validated stack choices recorded via interactive questions: Go `html/template` + HTMX (frontend stack), Go mock API server (mock data layer), all 5 screens (Reach signup, Stash dashboard, Window authorization, Standing + Freeholder signals, Bloom accrual), new top-level `web/` dir (UI code location).
| ID | Decision | Rationale | Confidence | Alternatives |
|----|----------|-----------|------------|--------------|
| D-066 | **Frontend stack = Go `html/template` + HTMX.** HTMX is a single vendored JS file served as a static asset — no node toolchain, no `package.json`, no build step. Go `html/template` is stdlib. **G-006 (zero-dep) is preserved** — this is the decisive factor vs. a React/Svelte SPA. Sufficient for Reach/Stash/Window/Standing/Bloom screens (progressive enhancement over server-rendered HTML). Weakest for rich dashboards, but adequate for an MVP prototype. | User-validated. Project has a strong zero-dep ethos (G-006); v0.5 took a controlled G-006 exception for cosmos-sdk only after GRILL ratification. A node toolchain + `package.json` would be a far larger exception for a UI MVP that can be served by stdlib + one vendored JS file. | 0.88 | [React/Vite SPA (adds node toolchain, breaks Go-only convention); SvelteKit (same tradeoff); pure static HTML/CSS/vanilla JS (most fragile)] |
| D-067 | **Mock data layer = Go HTTP server in `web/` instantiating real `x/*/types` structs.** New top-level `web/` dir holds `main.go`, HTTP handlers, an in-memory mock store seeded from fixtures, and `static/` + `templates/`. The mock store imports `x/identity/types`, `x/stash/types`, `x/window/types`, `x/standing/types`, `x/bread/types`, `x/bloom/types` and populates them with test values. **No keeper, no Cosmos runtime, no `app.go`** (none exists in the repo). This grounds the UI in the actual locked data shapes (Reach, Stash, Window, FreeholderSignals, BloomRecord) — the UI does not exercise a chain but does exercise the real Go type definitions. | User-validated. The four modules the Nomad UI primarily surfaces (identity, stash, window, standing) are types-only skeletons with no keeper/MsgServer. A Go mock server reuses the type definitions as the source of truth, so the UI is grounded in the locked constants (GrainsPerBread=10000, MaturityThresholdDays=90, standing formula) rather than mirroring them in TS/JSON. | 0.85 | [frontend-only TS/JSON fixtures (UI would not exercise any Go code path); Go mock API + in-memory keepers (more code, premature)] |
| D-068 | **UI code location = new top-level `web/` dir.** Clean separation from `x/` protocol modules; does not touch the `go.mod` module path; does not pretend to be a Cosmos module. `web/` contains `main.go` (or `cmd/oyd-ui/main.go`), handlers, mock store, fixtures, `static/`, `templates/`. | User-validated. The Mesh Experience component is ROADMAP Phase 2, not a v0.6 deliverable; coupling the UI to Cosmos module conventions (a new `x/meshexperience`) is premature. A top-level `web/` dir matches the project's existing convention of non-`x/` top-level dirs (`docs/`, `lexicon/`, `lexicon_meta_docs/`). | 0.90 | [new `x/meshexperience` Cosmos module (couples UI to Cosmos conventions prematurely); `cmd/oyd-ui` + `web/` split (more files, clearer build)] |
| D-069 | **Lexicon firewall extension to `web/`.** REQ-012 currently scans `x/` + `docs/`. A new sibling meta-test `lexicon_meta_web_test.go` (package `lexicon_meta_web`) scans `web/templates/**/*.html` + `web/static/**/*.js` for the 10 banned terms, using the same `lexicon.FindBannedTerm` + word-boundary regex. Self-exclusion + fragment pattern preserved. **"Sign up" maps to "Create a Reach"** — the word "account" is banned (REQ-012). Firewall-first: lands in P1 before content (P2..P5) so UI strings are lexicon-clean by construction. | REQ-012 is `All` phases and UI strings are user-facing; the firewall must cover the UI to be durable. Extending the existing meta-test pattern (not modifying it) preserves v0.2/v0.3 coverage. Firewall-first (D-044 pattern) ensures UI content is lexicon-clean by construction, not by retrofit. | 0.88 | [skip (REQ-012 is All phases); single combined meta-test scanning x/ + docs/ + web/ (loses isolation)] |
| D-070 | **G-003 firewall scope: `web/` importing `x/*/types` is app-layer consumption, not a cross-`x/` production import.** G-003 (production import firewall) prohibits production struct imports across `x/<module>/types` packages. `web/` is not an `x/` module — it is the application layer that consumes protocol types, exactly as a future `cmd/oyd` would. The G-003 firewall stays intact: no `x/` module gains a production import of another `x/` module's types via `web/`. GRILL reviews this boundary. | G-003's intent is to prevent cross-module coupling inside the protocol layer. The application layer consuming types is the intended consumption direction. `web/` importing `x/identity/types` is no different from `cmd/oyd` importing it (when one exists). | 0.85 | [treat `web/` as an `x/` module (wrong — it is not protocol); forbid `web/` from importing `x/*/types` (would force TS/JSON fixtures, losing the grounding in locked constants)] |
| D-071 | **"Sign up" = create a Reach + open a Stash atomically.** The Nomad entry path per `docs/nomads/reach.md` is "a Nomad starts with a Reach and a Stash". The signup form creates both atomically: a `Reach` with `IsNomad=true` + a `Stash` with `HolderID` matching the Reach's `HolderID` and `BalanceGrain` seeded to a test value (e.g., 500,000 Grain = 50 Bread). No KYC, no custodian (REQ-001 self-service principle). The UI labels this "Create a Reach" (lexicon-clean; "account" is banned). | The docs define the Nomad starting state as Reach + Stash. Creating only a Reach would leave the Nomad unable to view a Stash dashboard (P2) — the atomic creation matches the docs and makes the happy path contiguous. | 0.82 | [create Reach only, defer Stash creation to a separate flow (fractures the happy path); create Reach + Stash + Window all at signup (over-scope for an MVP)] |
| D-072 | **Phase ordering** (provisional, planner finalizes): P1 Web foundation + Reach signup + lexicon firewall extension (REQ-040 + REQ-045 — same `web/` territory, vertical slice, firewall-first) → P2 Stash dashboard (REQ-041, depends on Reach existing) → P3 Window authorization (REQ-042, depends on Stash existing) → P4 Standing + Freeholder signals (REQ-043, depends on Reach existing) → P5 Bloom accrual (REQ-044, depends on Stash existing) → P6 final review + audit + milestone ship. Each phase independently shippable; P1 lands the foundation + firewall first (lexicon-clean by construction). | P1 bundles the web foundation + Reach signup + the firewall extension (same `web/` territory, vertical slice). P2..P5 each add one screen, ordered by the Nomad happy path (Reach → Stash → Window → Standing → Bloom). Vertical slices, each phase shippable. | 0.82 | [different wave ordering; bundle Stash + Window in one phase] |
| D-073 | **Bread-scale source of truth = `x/bread/types` code constants, NOT `docs/shared/bread-scale.md`.** The code constants (`GrainsPerBread=10000`, `BreadScaleAll()` table) are the locked, tested values; the docs table is aspirational/outdated (states 1,000× ratios that do not match the code). The UI uses the code constants for all Bread-scale conversions. A doc-fix for `docs/shared/bread-scale.md` is flagged as a P1+ follow-up (not a v0.6 deliverable — docs were a v0.3 deliverable; this is a doc-drift fix, not a UI feature). | The code constants are tested (`x/bread/types/types_test.go` asserts them); the docs are not. Using the code as the source of truth keeps the UI consistent with the protocol layer. | 0.90 | [use the docs table (wrong — not tested, disagrees with code); fix the docs in v0.6 (out of scope — doc-drift fix, not a UI feature)] |