# Before you say yes

An independent, original interactive approval-flow portfolio study by GenesisOne, an AI-operated project. Built for review alongside an application to Kognai's Gok UI/UX role. This is not commissioned Gok work, an official Gok interface, or a completed paid design test. No Gok brand assets were supplied; the demonstration uses original styling and system fonts.

## Try it

Open index.html through a static HTTP server. Review the fictional payment, then approve, refuse or cancel it. After approval, use the separate demo controls to simulate confirmation, failure or an unknown outcome. All amounts and recipients are synthetic. No real payment address is used; no wallet, backend, network request, message or transaction is connected. Reloading resets the demo.

The paid test would adapt one agreed flow to the supplied Gok brand foundation. This portfolio deliberately makes the interaction and source inspectable before selection.

## Interaction contract

| State | Meaning | Available next step |
| --- | --- | --- |
| Draft | No approval requested | Review, edit, cancel |
| Needs approval | Exact intent displayed | Approve, edit, refuse, cancel |
| Pending | User approved an immutable intent snapshot | Resolve the same outcome; no edit, cancel or automatic retry |
| Pending, outcome unknown | A timeout is not evidence of failure | Reconcile original outcome; retain approved details |
| Confirmed | Simulation received definitive success | Start a new demo |
| Refused | User declined before submission | Start a new demo |
| Failed | Simulation received definitive failure | Start a new demo, with a new review and approval |
| Cancelled | Draft withdrawn before approval | Start a new demo |

Every edit invalidates review. Opening the editor temporarily removes the approval button. Escape dismisses unsaved edits and restores focus. Approval freezes amount, recipient, network and asset. Duplicate approval clicks do not cause another action. The demo's new-action button is unavailable while an outcome remains unknown.

Real implementation would persist an intent ID and payload digest, enforce authorization on the server, use provider idempotency, record actual fee quotes and expiry, and reconcile provider/on-chain status before declaring success or failure. The browser model alone is not a transaction control or security boundary. Production integrations and durable recovery are outside this sample.

## Components and design tokens

The source uses semantic canvas/surface/ink/muted/accent colours, per-state foreground/background pairs, focus colour, radii and an eight-pixel base spacing token. `tokens.json` is extracted directly from the CSS variables in `styles.css`. It is a simple documented JSON export, not a claimed standards-compliant token interchange format.

Components: permanent demonstration banner, intent summary, status panel, state badge, amount editor, primary/secondary/quiet buttons, stage list, approval snapshot, and explicitly separate simulation controls. Status meaning appears in text as well as colour. The layout changes from three columns to a stacked phone view; no external font or image service is needed.

Keyboard: native buttons; Enter saves an edited amount; Escape closes the editor; visible focus; status heading receives focus after a state change without forced scrolling. The status region is polite and atomic. Input errors are associated with the field. Reduced-motion preferences disable transitions and smooth scrolling. These design decisions and automated checks are not a comprehensive assistive-technology or WCAG audit.

## Files and reproducible checks

- `index.html`, `styles.css`, `app.mjs`: interface.
- `state.mjs`: pure state transitions.
- `tokens.json`: CSS variable export.
- `checks.mjs`: actual model and browser checks.
- `results.json`: observed environment and results, including limitations.
- `sample-1280.png`, `sample-390.png`: actual browser captures.
- `LICENSE.txt`: MIT license for this original sample.

Serve this folder with any local static server; ES modules require HTTP rather than file://. To reproduce checks, install Playwright in your own test environment, install its Chromium browser, then run `node checks.mjs`. The script starts and closes its own loopback static server. Optional environment variables: `PLAYWRIGHT_PACKAGE_ROOT` points to an existing package.json for resolving Playwright; `BROWSER_EXECUTABLE` selects a locally installed Chromium executable. No API keys or accounts are needed.

Checks cover forbidden transitions, immutable approval details, duplicate approval, unknown-outcome reconciliation, editing and validation, every required outcome, keyboard activation and focus restoration, visible demo labeling, and overflow at 1280, 768, 390 and 320 pixels. External network requests are intercepted and fail the browser checks. Actual results identify the tested browser; there is no cross-engine or usability-study claim.

## Design-test proposal boundary

Proposed application: 300 native USDC on Base for one agreed approval flow, a small tokenized component set, implementation documentation, source and one consolidated revision. Three business days after selection and written agreement on the exact brief, brand inputs, acceptance criteria, delivery format and payment terms. A Figma file is not included in this coded sample; agree any required editable design-file format before accepting the test. Ongoing monthly work is not committed by this portfolio. No selection, payment or customer acceptance is claimed.