neuron-explorer
Qwen3.5‑4B 전용 조향형 뉴런 탐색기, 모든 MLP 뉴런을 밀어 결과를 보관·탐색
캐셔가 결제 버튼을 누른 뒤 돈이 들어오기까지 일어나는 과정과 콜백이 신뢰할 수 없는 이유
What happens between a cashier pressing Charge and money arriving — and why the callback cannot be trusted. An independent teardown by Genmars.
개발 도구TypeScript · CSSGitHub @genmarstech온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Frontend work Genmars builds — client projects, product prototypes and
design implementations. One folder per project, each standing on its own.
One folder per project, independent. Each has its own package.json,
its own lockfile and its own stack. cd into one, install, run.
That is deliberate rather than lazy. These are separate pieces of work for
separate briefs, and a workspace monorepo would tie a grocery dashboard's
React version to whateveREADME 전문 보기 ↗Frontend work Genmars builds — client projects, product prototypes and design implementations. One folder per project, each standing on its own.
| Project | What it is | Stack |
|---|---|---|
mercato-admin | Grocery store operations dashboard — orders, inventory, delivery slots, team | Vite · React · TypeScript |
mercato-store | The same shop's storefront — aisles, basket, checkout, order tracking | Vite · React · TypeScript |
nero-26 | Formula 1 concept site — a car modelled in code, scroll-driven teardown, 3D tyre | Vite · React · TypeScript · three |
mvule-co | Nairobi furniture shopfront — KES pricing, WhatsApp ordering, M-Pesa deposits | Vite · React · TypeScript |
stk-lifecycle | R&D — interactive teardown of the M-Pesa STK push lifecycle, and why the callback cannot be trusted | Vite · React · TypeScript |
njia | Nairobi matatu arrival board — six real corridors, a deterministic morning, bunching detection, a map drawn with no map library | Vite · React · TypeScript |
shamba | Offline-first field survey — field-level CRDT merge on Lamport counters, and what whole-record last-write-wins quietly discards | Vite · React · TypeScript |
ratiba | Duty roster solver — backtracking with MRV in a cancellable Web Worker, and an explanation when no rota exists | Vite · React · TypeScript |
kioo | The Genmars design system — tokens, eight components, and contrast measured in the browser rather than documented | Vite · React · TypeScript |
mizani | Columnar query engine — dictionary-encoded store, a hand-written SQL subset, and a plan that says what it read | Vite · React · TypeScript |
deewee | DeeWee Natural Oils — a hair-oil shopfront built from a Claude Design handoff, with a two-question routine quiz and a draggable before/after | Vite · React · TypeScript |
One folder per project, independent. Each has its own package.json,
its own lockfile and its own stack. cd into one, install, run.
That is deliberate rather than lazy. These are separate pieces of work for
separate briefs, and a workspace monorepo would tie a grocery dashboard's
React version to whatever lands next. Coupling projects that need not agree
buys a smaller node_modules and costs the ability to pin anything.
Two of them share a brand rather than a build. mercato-admin and
mercato-store are the staff and customer halves of one shop and carry the
same palette and the same three typefaces — each copied into its own
theme.ts, not imported from a shared package. A duplicated palette is the
cheaper mistake: extracting it would make a colour change in one deploy a
rebuild of the other, for two projects that are each finished.
Each project carries its own README with what it is and how to run it.
They are demonstrations, and each one is built around a single engineering argument it can make better than a sentence can:
njia — that a city-scale map needs a projection, not a map library,
and that a simulation whose history depends on how you arrived at a
moment cannot be used to argue about anything.shamba — that the merge rule most sync layers ship converges
perfectly and is still losing data, and that the list of six discarded
observations is the argument the abstract one never wins.ratiba — that the valuable output of a solver is the one where it
fails, and that "no solution found" is true and useless.kioo — that a design system's accessibility figures should be
measured rather than written down. It found a real failure in its own
tokens the first time it ran.mizani — that storing down the columns is worth it, and that a
query plan which reports what it actually touched is how you know.Charter 03 §I runs through all of them. Between the five there is no map
library, no SQL parser, no dataframe library, no charting library, no CSV
library, no constraint solver and no CRDT library. The only runtime
dependency any of them has beyond React is three, in nero-26.
projects/<name>/
README.md what it is, how to run it, where the design came from
package.json with a `verify` script CI can call
Give it a verify script that does whatever "this is not broken" means for
that stack — typecheck and build, at minimum. It is the one convention
worth holding across otherwise independent projects.