# octrascan design system - complete LLM design brief
This file is the complete design brief for generating, reviewing, or refactoring Octra explorer, wallet, dashboard, and DeFi interfaces in the octrascan visual language. Treat it as the first file to read before editing UI. It is intentionally more detailed than a normal README so an LLM can reproduce the design without guessing. [S1][S2][S3][L1][L3]
## 1. Source map
External sources:
- [S1] octrascan lite scanner: https://octrascan.io/
- [S2] octrascan browse surface: https://octrascan.io/browse
- [S3] octrascan all transactions surface: https://octrascan.io/txs.html
- [S4] W3C Design Tokens Community Group: https://www.w3.org/community/design-tokens/
- [S5] Atlassian Design System overview: https://atlassian.design/design-system
- [S6] Atlassian Foundations: https://atlassian.design/foundations/
- [S7] Shopify Polaris foundations: https://polaris-react.shopify.com/foundations
- [S8] Polaris color tokens: https://polaris-react.shopify.com/design/colors/color-tokens
- [S9] Carbon color and token guidance: https://carbondesignsystem.com/elements/color/overview/
- [S10] Material Design tabs guidance: https://m1.material.io/components/tabs.html
- [S11] Material Design dialogs guidance: https://m1.material.io/components/dialogs.html
- [S12] Material Design menus guidance: https://m1.material.io/components/menus.html
- [S13] Material Design lists guidance: https://m1.material.io/components/lists.html
Local sources:
- [L1] `octrascan-ui-kit/source/style.css` - original octrascan visual values and CSS structure.
- [L2] `octrascan-design-system/README.md` - concise project summary.
- [L3] `octrascan-design-system/styles.css` - implemented design-system CSS.
- [L4] `octrascan-design-system/index.html` - implemented docs, components, patterns, DeFi examples, governance.
- [L5] `octrascan-design-system/app.js` - implemented interactions.
## 2. Design thesis
The octrascan style is a dense, task-first explorer interface for blockchain data. It should feel like a precise network instrument: small type, exact labels, rule-based layout, muted blue-gray surfaces, table-first data, and visible status text. It is not a glossy crypto landing page. [S1][S2][S3][L1]
World-class design-system structure should include foundations, components, patterns, tokens, accessibility, content rules, tools/usage paths, maturity, release phases, and contribution criteria. Atlassian and Polaris both organize systems around foundations and components, while W3C/Carbon/Polaris emphasize tokens as reusable design decisions. [S4][S5][S6][S7][S8][S9]
Material-style component docs inform how to document component usage, behavior, states, specs, and "do not use this when..." guidance. Apply that rigor while preserving octrascan's minimal visual language. [S10][S11][S12][S13]
## 3. Product personality
Use these words as the target tone:
- dense
- exact
- quiet
- technical
- transparent
- inspectable
- low decoration
- high signal
- scanner-like
- terminal-adjacent
- protocol-literate
Avoid:
- glossy
- luxury
- neon
- bubbly
- hero-heavy
- illustration-led
- card-stacked marketing pages
- vague DeFi copy
- color-only status communication
Rationale: octrascan itself presents a compact explorer with build/status/search/metrics/tables/footer rather than an editorial landing page. [S1][S2][S3]
## 4. Core page anatomy
The default app structure should be:
1. Top header: product title, network/build subtitle, status chip, optional action buttons. [S1][L3]
2. Optional sidebar: docs/search/navigation for design-system docs or application modules. [S5][S6][L4]
3. Main content: full-width sections separated by 1px rules. [S1][S2][L1][L3]
4. Search/query bar: one global search or scoped filter. [S1][S2][L3]
5. Metrics row: dense stat boxes for epoch, transactions, supply, staging, mcap, price, validators, TVL, APY, utilization, etc. [S1][S2][L3]
6. Primary data surface: tables first on desktop. [S1][S2][S3][L3]
7. Mobile fallback: cards that preserve the same labels as table headers. [S2][S13][L3]
8. Footer/status strip: product/legal/build/network note. [S1][L1]
Do not build a marketing hero as the first product screen unless the task explicitly asks for a public landing page. For product tools, the first viewport should be usable. [S5][S7]
## 5. CSS token contract
All new UI must use these CSS variables. Do not hardcode colors, spacing, font stacks, or row heights in component CSS unless adding a new documented token. Token usage follows the W3C/Carbon/Polaris principle of named design decisions instead of raw values. [S4][S8][S9][L3]
Light theme color tokens:
```css
--oct-color-bg: #ffffff;
--oct-color-text: #000000;
--oct-color-surface: #e5e9ef;
--oct-color-surface-soft: #f6f7f9;
--oct-color-header: #d0d7e2;
--oct-color-border: #d0d7e2;
--oct-color-border-strong: #c0c6d0;
--oct-color-primary: #3b567f;
--oct-color-primary-soft: #516e9a;
--oct-color-muted: #8c9db6;
--oct-color-success: #15803d;
--oct-color-warning: #ca8a04;
--oct-color-warning-bg: #fffbeb;
--oct-color-danger: #dc2626;
--oct-color-danger-bg: #fef2f2;
--oct-color-code-bg: #172033;
--oct-color-code-text: #e5e9ef;
```
Dark theme color tokens:
```css
--oct-color-bg: #111722;
--oct-color-text: #edf2f7;
--oct-color-surface: #1e293b;
--oct-color-surface-soft: #172033;
--oct-color-header: #263449;
--oct-color-border: #334155;
--oct-color-border-strong: #475569;
--oct-color-primary: #a9c4ee;
--oct-color-primary-soft: #6f8dbb;
--oct-color-muted: #94a3b8;
--oct-color-warning-bg: #302712;
--oct-color-danger-bg: #351a1a;
```
Typography tokens:
```css
--oct-type-ui: Tahoma, Arial, sans-serif;
--oct-type-mono: "SF Mono", Consolas, Monaco, monospace;
--oct-type-size-01: 10px;
--oct-type-size-02: 11px;
--oct-type-size-03: 12px;
--oct-type-size-04: 16px;
--oct-line-height: 150%;
--oct-letter-space: 1px;
```
Spacing tokens:
```css
--oct-space-01: 2px;
--oct-space-02: 4px;
--oct-space-03: 6px;
--oct-space-04: 8px;
--oct-space-05: 10px;
--oct-space-06: 14px;
--oct-space-07: 18px;
--oct-space-08: 24px;
```
Component tokens:
```css
--oct-radius-none: 0;
--oct-shadow-focus: 0 0 0 2px rgba(59, 86, 127, 0.24);
--oct-component-header-height: 38px;
--oct-component-sidebar-width: 220px;
--oct-component-table-row-height: 28px;
```
Compact density overrides:
```css
--oct-space-04: 6px;
--oct-space-05: 8px;
--oct-component-table-row-height: 24px;
```
## 6. Color rules
Use `--oct-color-bg` for pages and repeated cards. Use `--oct-color-surface` for headers, search bands, metric rows, and toolbar zones. Use `--oct-color-surface-soft` for table headers and secondary panels. Use `--oct-color-header` for app bars and section bars. Use `--oct-color-primary` for product title, links, key metric values, selected nav, and primary actions. Use `--oct-color-muted` for labels, helper text, subtitles, and inactive controls. [L1][L3]
Use support colors sparingly:
- Success: verified, active, done, safe, encrypted-ready. [L3]
- Warning: staging, relay, priority, vote-in-progress, non-final settlement. [S1][S2][L3]
- Danger: rejected, invalid, destructive, liquidation risk, RPC failure. [S1][L3]
Never communicate status with color alone. Every status must have text like `staging`, `rejected`, `confirmed`, `pending`, `safe`, `proof`, or `relay`. This follows accessibility and product clarity principles. [S5][S7][S11][L3]
## 7. Typography rules
Base UI text is `Tahoma, Arial, sans-serif`, 11px, line-height 150%, letter-spacing 1px. This is inherited from the octrascan source and must remain the dominant texture. [L1][L3]
Use `SF Mono, Consolas, Monaco, monospace` for:
- transaction hashes
- wallet addresses
- epochs
- amounts
- prices
- APY/APR values
- code snippets
- token names
- protocol identifiers
- route strings
- build IDs
Type scale:
- 10px: tags, metadata, token values, source links.
- 11px: default body, tables, labels, nav, buttons.
- 12px: header title, key metric values, compact headings.
- 16px: documentation H1 only, not component card headings.
Do not use oversized hero typography in app panels. Display type is only acceptable in a public marketing page, not in scanner/dApp surfaces. [S1][S5][S7][L3]
## 8. Layout rules
Use square edges and 1px borders. Border radius is zero by default. Card radius should remain zero unless the surrounding project already has a radius system. [L1][L3]
Use full-width section bands rather than floating cards inside cards. Page sections should be divided by `.section-title` bars and 1px rules. Individual repeated items can use cards only when they are actual repeated items or mobile table fallbacks. [S1][S2][S13][L3]
Desktop layout defaults:
- Header height: 38px.
- Sidebar width: 220px.
- Table row height: 28px.
- Compact row height: 24px.
- Section padding: usually 8px to 14px.
- Large preview padding: 24px.
Responsive layout:
- Below 1100px: documentation and DeFi grids generally move from 3/4 columns to 2 columns.
- Below 760px: sidebar becomes horizontal nav, docs search hides, metrics wrap to 3 columns, DeFi windows become 1 column, wide orderbook stacks vertically, tables scroll horizontally or convert to cards.
## 9. Navigation and docs search
Use `.kit-sidebar` for design-system documentation or multi-module tools. Sidebar contains `.docs-search`, `.kit-nav`, and optional `.sidebar-note`. [S5][S6][L3][L4]
Navigation labels should be lowercase, short, and literal:
- overview
- source audit
- quality bar
- foundations
- tokens
- components
- usage rules
- patterns
- defi examples
- states
- contracts
- governance
- accessibility
Active nav uses primary color/text contrast and a bottom border. Hidden search-filtered nav items use `.is-filtered`. [L3][L5]
## 10. Header component
Use `.oct-header` for the top app shell. It contains `.oct-header__left`, `.oct-header__title`, `.oct-header__subtitle`, and `.oct-header__right`. [S1][L3]
Header title examples:
- `octrascan (lite) | main net`
- `octrascan design system`
- `octra app | private defi`
- `octra wallet | encrypted balance`
Subtitle examples:
- `build axFH017/2026`
- `main net`
- `devnet`
- `proof queue online`
- `wallet offline`
Header right area can contain `.status-chip`, connect button, theme toggle, density toggle, or network chip. Keep it compact. [L3]
## 11. Search/query fields
Use `.search-bar` for a full-width scanner query. Use `.query-field` for compact filters in toolbars. [S1][S2][L3]
Placeholder copy should be explicit:
- `search by tx hash, address, or epoch id...`
- `search transactions, addresses and blocks`
- `tokens, defi, governance...`
- `button, badge, table, search...`
Search fields should use a 1px strong border and primary focus ring. Do not remove focus indicators. [S5][S9][L3]
## 12. Buttons
Button classes:
- `.button`
- `.button--primary`
- `.button--quiet`
- `.button--danger`
Use primary buttons for submit, load, preview, stake, connect, and confirm actions. Use default buttons for navigation or secondary actions. Use quiet buttons for toolbar actions like update list. Use danger only for destructive/rejected flows. [L3]
Button text should be short and lowercase:
- `load more`
- `back to scanner`
- `update list`
- `preview swap`
- `stake`
- `unstake`
- `reject`
Disabled buttons must remain visible with muted text. Do not remove disabled actions if their existence helps users understand the workflow. This follows menu/action guidance that disabled actions can clarify availability. [S12][L3]
## 13. Status chips, badges, and tags
Use `.status-chip` for persistent system/network state:
- `connecting...`
- `epoch 282,119`
- `wallet offline`
- `health 1.82`
- `3 pending`
- `mark $0.1284`
Use `.tag` plus variants for inline state:
- `.tag--op`: operation type, e.g. `transfer`
- `.tag--confirmed`: `confirmed`, `done`, `safe`, `active`
- `.tag--staging`: `staging`, `relay`, `normal`, `epoch vote`
- `.tag--rejected`: `rejected`, `invalid`, `failed`
- `.tag--ocs`: `ocs01`, `encrypted`
- `.tag--pending`: `pending`, `proof`
Tags are 10px, compact, textual, and square. Do not use unlabeled dots. [S1][S2][L1][L3]
## 14. Metrics row
Use `.metrics-row` and `.metric` for horizontally comparable stats. [S1][S2][L3]
Explorer metric examples:
- epoch
- transactions
- supply
- staging
- mcap
- price
- total txs
- total volume
- total accounts
- validators
- peak tps
DeFi metric examples:
- supply apy
- borrow apy
- utilization
- tvl
- 24h vol
- apr
- health
- mark
- claimable
Metric label is muted lowercase. Metric value is primary, bold, and ellipsized if needed. [L3]
## 15. Tables
Tables are the primary desktop data display. Use `.data-table`. Do not replace comparable blockchain/DeFi data with decorative cards on desktop. [S1][S2][S3][L3]
Explorer table columns:
- transactions: hash, epoch, time, from, to, amount
- epochs: epoch, txs, time, tree hash, parent commit, validator
- browse transactions: hash, timestamp, amount, priority
- bridge queue: tx, asset, side, state
DeFi table columns:
- pools: pool, tvl, 24h vol, apr
- orderbook: bid, size, ask, size
- governance/release: phase, meaning, ship rule
Table rules:
- Use `table-layout: fixed` for predictable truncation.
- Table headers are lowercase, muted/primary-soft, and on soft surface.
- Cells use ellipsis and no wrapping by default.
- Use mono for hashes, addresses, prices, amounts.
- Use `.row--staging` for staged rows.
- Use `.row--rejected` for rejected rows.
- Hover is subtle surface-soft only.
## 16. Detail tables
Use `.detail-table` for object metadata, swap quotes, positions, governance proposal attributes, and wallet details. [L3]
The first column is a muted label, fixed around 150px. The second column can wrap and use mono where appropriate. [L3]
Detail row examples:
- route: `OCT -> pUSD`
- fee: `0.30%`
- price impact: `0.18%`
- settlement: `staging`
- supplied: `12,400 OCT`
- borrowed: `4,820 pUSD`
- liquidation: `$0.081 OCT`
- private balance: `encrypted`
- last sync: `epoch 282119`
## 17. Mobile cards
Use `.card-list` and `.tx-card` only when a dense table needs a responsive fallback. Card labels must match the desktop table headers exactly. [S2][S13][L3]
Card anatomy:
- `.card-row`
- `.card-label`
- `.card-val`
- optional `.tx-card--rejected`
Card values should ellipsize. Hash/address values should remain mono and clickable if appropriate. [L3]
## 18. Loading, empty, alert, toast
Use direct, literal states:
- `.loading-line`: `loading...`
- `.empty-line`: `no recent transactions`
- `.alert.alert--error`: `rpc timeout - retrying in 4s`
- `.toast`: `copied token name`
Errors should name the failed thing:
- `rpc timeout`
- `proof missing`
- `invalid epoch`
- `wallet locked`
- `insufficient balance`
- `route unavailable`
Dialogs/modals should be used sparingly because they interrupt the task. Prefer inline alerts, detail rows, or toast unless a destructive or irreversible decision needs explicit confirmation. [S11][L3]
## 19. Component completeness checklist
A component is not design-system ready unless it documents: [S5][S6][S9][S10][S11][L4]
- purpose and usage scope
- anatomy and slots
- variants
- states
- layout rules
- overflow/truncation behavior
- responsive behavior
- keyboard/focus behavior
- accessibility notes
- content rules
- tokens used
- implementation classes
- test strings
- "do not use when" guidance
- maturity phase
## 20. Foundation principles
Principles:
- Scanner first: information density beats decoration. [S1][S2][S3]
- Every state has a visible text fallback. [S5][S11]
- Tables remain tables on desktop; cards take over on mobile. [S2][S13][L3]
- Use semantic tokens in components, not raw hex values. [S4][S8][S9]
- Labels are literal and lowercase. [S1][S2][L1]
- Motion is stateful, not decorative. [L3]
- Actions must be adjacent to the data they affect. [S12][L4]
## 21. Content design
Voice:
- concise
- literal
- protocol-aware
- no hype
- no vague "magic"
- no unexplained risk
Label style:
- lowercase labels
- short nouns for table headers
- exact state names
- no decorative punctuation
Good labels:
- epoch
- transactions
- supply
- staging
- validators
- peak tps
- route
- fee
- price impact
- settlement
- proof
- relay
- claimable
- liquidation
Bad labels:
- explore the future
- unleash privacy
- supercharge your journey
- next-gen dashboard experience
- amazing rewards
DeFi action copy must reveal important trade information before the action: route, fee, price impact, settlement state, collateral/health, liquidation, bridge state, and proof state. [S11][L4]
## 22. States matrix
Use these states consistently:
- default: normal control or row
- hover: subtle border/surface strengthening
- focus: visible 2px focus ring via `--oct-shadow-focus`
- pressed: primary-soft or active border
- disabled: muted text, soft surface, no pointer affordance
- loading: visible text `loading...`
- empty: visible text, often italic muted
- error: danger text/background and specific message
- selected: primary text and active bottom rule
- open: selected/open control state
- staging: warning background or tag
- rejected: danger background or tag
- confirmed: textual confirmed/done/safe state
- pending: textual pending/proof with limited pulse
Do not introduce synonyms that split the state vocabulary. For example, use `pressed` or `selected`, not random `active-ish` states. [S9][S10][S11][L3]
## 23. Motion
Motion is nearly absent. The only built-in animation is `.tag--pending` pulse, using steps. Use it only for pending/proof/staging states. [L3]
Do not add:
- animated gradient backgrounds
- floating blobs
- particle effects
- decorative parallax
- constant chart wiggles with no data meaning
If chart bars change, they should represent actual data state or explicit mock data in examples. [L4]
## 24. DeFi interface recipes
DeFi examples should look like protocol tools grafted onto octrascan, not like generic web3 dashboards. [L4]
### Swap ticket
Required anatomy:
- header: title + subtitle + protocol tag
- pay field
- receive field
- route row
- fee row
- price impact row
- settlement row
- primary `preview swap` action
Use `.defi-window`, `.defi-window__header`, `.defi-ticket`, `.defi-field`, `.detail-table`, `.button--primary`. [L3][L4]
### Lending market
Required anatomy:
- header with health chip
- metrics row: supply APY, borrow APY, utilization
- risk meter
- detail table: supplied, borrowed, liquidation, status
Use health text and liquidation price. Never show a lending action without risk context. [S11][L4]
### Liquidity pools
Required anatomy:
- header with update action
- table columns: pool, tvl, 24h vol, apr
- mono values for numbers
Pools should be table-first because users compare rows. [S13][L4]
### Staking vault
Required anatomy:
- header with active state
- staked amount
- pending rewards
- unbonding period
- validator allocation bars
- stake/unstake actions
Do not hide unbonding time. [L4]
### Bridge queue
Required anatomy:
- header with pending count
- table columns: tx, asset, side, state
- state tags: proof, relay, done
Bridge states must be textual because users need to understand transaction progress. [S11][L4]
### Portfolio
Required anatomy:
- total value
- allocation strip
- detail table for daily pnl, claimable, private balance, last sync
Use mono for totals and epoch sync. [L4]
### Perp/orderbook
Required anatomy:
- header with mark price
- bid/ask table
- compact market depth chart
- mono prices and sizes
Orderbook layout is table plus chart on desktop, stacked on smaller screens. [L4]
### Governance proposal
Required anatomy:
- proposal summary
- for/against/quorum rows
- vote bar
- state tag such as `epoch vote`
Governance must show quorum and vote split, not only a CTA. [L4]
## 25. Screen patterns
### Scanner home
Header, search, six metrics, optional staging section, recent transactions, recent epochs, footer. [S1][L4]
### Browse
Nav, aggregate metrics, epochs heading, transactions table, update list action, all transactions link. [S2][L4]
### Transactions
Back link, transaction count, loading/empty state, load more button, hash/epoch/time/from/to/amount columns. [S3][L4]
### Address detail
Address heading, balance summary, received/sent rows, program tags, token badges, storage/detail tables. Use same table/detail-table primitives. [S1][S3][L4]
### Design-system docs
Header, sidebar docs search, nav, source audit, quality bar, foundations, tokens, components, usage rules, patterns, DeFi examples, states, contracts, governance, accessibility. [S5][S6][S7][L4]
## 26. Accessibility
Accessibility requirements:
- Visible focus ring for links, buttons, and inputs. [S5][S9][L3]
- Real table markup for tabular data. [S13][L4]
- Table headers must describe columns. [S13][L4]
- Mobile cards must preserve labels. [S13][L3]
- Color-coded states must include visible text. [S5][S11][L3]
- Buttons must have readable text labels.
- Inputs must have labels or screen-reader labels.
- Do not use tooltip-only explanations for critical risk. Tooltips may supplement but not replace visible labels. [S11][S12]
- Error messages must identify the failed action.
- Do not trap users in unnecessary dialogs. [S11]
## 27. Do / don't
Do:
- Use semantic token names in component CSS. [S4][S8][S9]
- Show exact fees, routes, epochs, hashes, and settlement state. [S1][S2][S3][L4]
- Keep actions near the affected data. [S12]
- Prefer tables for scanner and DeFi comparisons. [S1][S2][S3][S13]
- Make loading, empty, rejected, and staging states explicit. [S1][S3][L3]
- Use mono for protocol values. [L1][L3]
- Keep copy short and literal. [S5][S7]
Don't:
- Do not hide risk behind color-only badges. [S5][S11]
- Do not use marketing hero layouts inside app surfaces. [S5][S7]
- Do not create one-off DeFi widgets without a reusable contract. [S4][S9]
- Do not truncate amounts, routes, or error causes without a detail view. [S11][L4]
- Do not use cards inside cards. [L3]
- Do not add gradient blobs, bokeh, or ambient decorations.
- Do not make the palette one-note purple/blue crypto neon.
- Do not remove focus outlines.
- Do not invent new state names when existing ones fit.
## 28. Governance and maturity
Every component or pattern should have a release phase: [S5][S6][L4]
- experimental: new recipe or visual idea, prototype only.
- beta: usable, API may move, allowed with owner approval.
- stable: contract frozen, default for product UI.
- deprecated: replacement exists, migration required.
Contribution checklist:
- Appears in at least three product surfaces or one critical flow.
- Uses existing tokens unless a semantic gap is proven.
- Includes desktop and mobile examples.
- Includes loading, empty, error, disabled, and focus states.
- Names owner, maturity, migration notes, and test strings.
- Documents source citations and local implementation hooks.
Current changelog:
- 0.3.0: DeFi recipes, governance, quality bar, usage rules.
- 0.2.0: component gallery, tokens, states, accessibility.
- 0.1.0: octrascan scanner foundations.
## 29. Implementation classes
Layout:
- `.app-shell`
- `.oct-header`
- `.oct-header__left`
- `.oct-header__title`
- `.oct-header__subtitle`
- `.oct-header__right`
- `.kit-layout`
- `.kit-sidebar`
- `.kit-main`
- `.section`
- `.section-title`
- `.section-title--nested`
Docs:
- `.docs-search`
- `.kit-nav`
- `.sidebar-note`
- `.source-link`
- `.system-status-grid`
- `.quality-layout`
- `.quality-card`
- `.role-grid`
- `.release-rail`
- `.usage-grid`
- `.usage-card`
- `.governance-grid`
- `.governance-card`
- `.changelog`
Components:
- `.button`
- `.button--primary`
- `.button--quiet`
- `.button--danger`
- `.status-chip`
- `.status-chip--static`
- `.search-bar`
- `.query-field`
- `.metrics-row`
- `.metrics-row--mini`
- `.metric`
- `.data-table`
- `.detail-table`
- `.tag`
- `.tag--op`
- `.tag--confirmed`
- `.tag--staging`
- `.tag--rejected`
- `.tag--ocs`
- `.tag--pending`
- `.card-list`
- `.tx-card`
- `.tx-card--rejected`
- `.loading-line`
- `.empty-line`
- `.alert`
- `.alert--error`
- `.toast`
DeFi:
- `.defi-intro`
- `.defi-grid`
- `.defi-window`
- `.defi-window--swap`
- `.defi-window--portfolio`
- `.defi-window--wide`
- `.defi-window__header`
- `.defi-ticket`
- `.defi-field`
- `.swap-direction`
- `.risk-meter`
- `.vault-stack`
- `.vault-row`
- `.validator-bars`
- `.portfolio-strip`
- `.orderbook-layout`
- `.mini-chart`
- `.vote-bar`
- `.vote-bar__for`
- `.vote-bar__against`
State helpers:
- `.muted`
- `.helper-text`
- `.mono`
- `.amount`
- `.row--staging`
- `.row--rejected`
- `.is-hidden`
- `.is-filtered`
- `.sr-only`
## 30. HTML patterns to copy
Header:
```html
```
## 31. Applying this to octra.app
When refactoring `octra.app`, preserve its product functionality and replace only the interface layer unless explicitly asked to change behavior.
Recommended migration order:
1. Add root design tokens from section 5.
2. Replace top navigation/header with `.oct-header`.
3. Convert dashboard stats to `.metrics-row`.
4. Convert transaction, pool, position, bridge, or governance lists to `.data-table`.
5. Convert object metadata/quotes to `.detail-table`.
6. Replace pill/badge styling with `.tag` variants.
7. Add visible loading/empty/error states.
8. Add `llms.txt` at repo root with this design brief or a repo-specific adaptation.
9. Verify desktop and mobile.
10. Run the repo's existing lint/build/tests.
Do not rewrite wallet, bridge, contract, or transaction logic just for styling. Keep behavioral diffs small unless the user asks for product changes.