AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
Berit Alasmäki's portfolio concept screen for reviewing and approving AI agent changes before release
Translation pending
AI summary · revised during review
Developer toolsTypeScript · CSSGitHub @beritalasmakiOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Loading the full README. The saved excerpt is shown below.
☝️ See the design folder for the mockups and how the page got here. ☝️ A published Storybook is coming soon. An AI agent has made a change to a customer's software. Before that change is released, a person has to understand what the agent did, see which checks passed or failed, judge how sure the agent was and why, and then approve, ask for changes, or reject. This repository (demo-t-example) is that one review screen. It is a portfolio piece built to the standard of a real product surface, not a mockup. It is not affiliated with any company, and every run in it is fictional.Read the full README ↗
👀 View the screen: https://demo-t-example.vercel.app/
☝️ See the design folder for the mockups and how the page got here.
☝️ A published Storybook is coming soon.
An AI agent has made a change to a customer's software. Before that change is released, a
person has to understand what the agent did, see which checks passed or failed, judge how sure
the agent was and why, and then approve, ask for changes, or reject. This repository
(demo-t-example) is that one review screen.
It is a portfolio piece built to the standard of a real product surface, not a mockup. It is not affiliated with any company, and every run in it is fictional.
Nothing on the page is decided by the interface. Every number and status comes from the run's
data and links to its evidence, and anything unknown says "unknown". The rules behind this are
in AGENTS.md.
Light and dark themes both work, switched from the top of the page (or following the system
setting until you choose), the whole page works from the keyboard, status is never shown
by colour alone, and motion respects prefers-reduced-motion.
The app opens on My reviews, the reviewer's list. Other states are one URL away:
| URL | What it shows |
|---|---|
/ | My reviews: tabs, search, filters, archive and reports |
/?run=run-messy-pending | a run awaiting review: checks that did not run, a low score, an open note |
/?run=run-clean | everything passed; nothing to solve |
/?run=run-blocked | a failed check, an exception, and an error and retry in the steps |
/?run=run-messy | the same run as run-messy-pending, already approved, in its undo window |
/?delay=3000 | any of the above, with the load slowed down to show the loading state |
There is no backend. Runs are typed fixtures in src/fixtures/, served through getRun() in
src/lib/api.ts, so a real API can replace them without touching the interface. Decisions and
undos last for the browser tab: they hold across pages and reloads, and a new tab starts
every run over.
src/styles/tokens.cssthinking-orbs (the loading orb)e2e/ (the approve flow and a decline after an
undo, keyboard-only runs of the review and of My reviews, and axe WCAG A/AA and contrast
checks in both themes; 35 tests in all), and the theme-colour checkDependencies point one way, fixtures → lib → components → features → app, and a lint rule
(import/no-restricted-paths) enforces it. components/ and styles/ are the design system
and know nothing about agent runs.
Needs Node.js 20.19 or newer (22.12 or newer on the 22 line).
npm install
npx playwright install chromium # once: npm run check uses it for the end-to-end and theme checks
npm run dev # start the app
npm run storybook # start Storybook, on components and design tokens
npm run check # the gate for any change: typecheck, lint, format, theme and locale checks, tests, end-to-end
npm run test:e2e # the Playwright specs alone (starts the app itself)
npm run test:watch # tests, watching
npm run lint:fix # eslint --fix
npm run format # prettier --write
npm run build # production build of the app
npm run build-storybook # static Storybook build
STORY.mddocs/spec-review-screen.mdAGENTS.mddocs/DECISIONS.mddocs/WORKLOG.mdREADME.md in each folder under src/The review screen is built. It follows the redesign from Claude Design, with its later iterations: the three-column layout, the Story, Evidence and All steps views, the decision panel with undo, the welcome intro and the loading state. My reviews is built to its own Claude Design handoff (DECISIONS 0060). A polish pass and a cleanup have removed the code the redesign left behind.
The end-to-end approve flow is a committed Playwright spec. The end-of-project accessibility
review was done as a lighter, time-boxed pass, not a full audit: automated WCAG A/AA and
contrast checks in both themes, and a keyboard-only pass of the whole review. Both now run on
every npm run check. What that pass did not cover is listed in
DECISIONS 0059.
Still to do: