Shojin Pass — verdict and rulebook engine
The part of the backend that decides green / amber / red for a Japanese food label and a diet.
Pure JavaScript (Node 20+), no network. Spec: Shojin Pass Backend Architecture v2.1.
npm install
npx vitest run # 220 tests
node scripts/evalText.js # 138 edge cases, one line each
node scripts/validateRulebook.js # rulebook checks (add --strict for release, --report for details)
node scripts/genSynthetic.js 500 # generated adversarial labels (fixed seed)
import { getRulebook } from './lib/rulebook/loader.js';
import { scanLabel } from './lib/scan/scanText.js';
const r = scanLabel({ raw: '原材料名：小麦粉、ラード\n内容量：100g', preset: 'jain_strict', lang: 'hi' }, getRulebook());
// r.verdict 'red', r.verdictLine, r.why, r.items, r.reasons ...
Before release: every rulebook entry has reviewedBy: []. Two people must review each one.
Until then set RULEBOOK_ALLOW_UNREVIEWED=true in development; without it, no ingredient is
trusted and every label is amber (by design).
The reviewers' checklist docs/rulebook-review.csv (for Google Sheets; npm run review:doc writes it
and docs/rulebook-review.md) has a jmdict_meaning column: the English meaning of each entry's
Japanese term in JMdict, to compare with ours. It comes from data/jmdict-extract.json, the few
JMdict entries for those terms, built with
node scripts/buildJmdictExtract.js path/to/JMdict_e.gz (download
JMdict_e.gz; keep it outside the repo). The engine
never reads it, and terms JMdict doesn't have show (not in JMdict).
Reviewers fill the reviewer1, reviewer1_ok, reviewer2, reviewer2_ok and correction_notes
columns in the Sheet. Download it as CSV and run npm run review:import -- path/to/export.csv (a dry
run that only prints a report), then add --write to record the sign-offs in reviewedBy in
rulebook/ingredients.json. A name counts when its _ok cell is yes, ok, TRUE, 1 or ✓. A row with
correction notes, or with a reviewer who didn't say yes, adds nobody and is listed in the report.
Tags, spellings and meanings are never changed by the import.
JMdict credit: this project uses the JMdict
dictionary files. These files are the property of the
Electronic Dictionary Research and Development Group (EDRDG) and are used in
conformance with the Group's licence: Creative Commons
Attribution-ShareAlike 4.0 (CC BY-SA 4.0). data/jmdict-extract.json and the jmdict_meaning column
of docs/rulebook-review.csv are derived from JMdict and are shared under the same licence.
| Folder | What |
|---|
rulebook/ | tags, presets, options, ingredients (125 entries, ~1,800 spellings), annotations, field markers, chef phrases |
lib/rulebook/ | normalise → find sections → match → verdict |
lib/scan/analyze.js | the whole pure pipeline for one label |
lib/text/templates.js | fixed verdict lines and "why" sentences in English, Hindi, Gujarati |
tests/ | unit tests, 138 edge cases, property tests over every spelling, generated adversarial labels |
Frontend (app screens)
Next.js App Router · React 19 · TypeScript for the screens (.tsx) next to the JavaScript backend ·
Tailwind CSS 3 · Framer Motion · lucide-react. Fonts are self-hosted with Fontsource, so the site
builds and runs without reaching Google Fonts. Built by Team Kakehashi 架け橋.
npm run dev # http://localhost:3000
npm run build && npm start
| Route | What it is |
|---|
/ | Landing page: hero, how it works, features, shōjin ryōri insight, FAQ |
/scanner | Trust Scanner: family members with their diets, samples / photo / pasted text, verdict + reason in English, हिंदी or ગુજરાતી |
/routes · /routes/[slug] | Shojin Routes list and detail with timeline and a (demo) booking form |
/venues | Partner venues on a stylised Kyoto / Koyasan map, filtered by type and your diet |
/chef-card | Show the Chef: polite Japanese card for your diet, tap-to-reply answers, printable |
/partners | For tourism bodies and venues: 10-point checklist self-check (demo form) |
/about | Story, success metrics, team |
/dev | Backend test console (not on production) |
The screens live in app/(screens)/ with their own layout (header, footer, providers); /dev stays
outside it. Every verdict comes from the server through lib/client/shojinClient.js: the screens never
judge an ingredient and never call fetch themselves. Photos check Person 1's diet first ("Check for
everyone" scans the rest); text and samples check everyone at once.
Where to edit things:
lib/ui/content.ts: landing-page copy, stats, FAQ.lib/ui/site-data.ts: Shojin Routes, venues (demo data until stage 5), certification checklist.lib/ui/diets.ts: the diet pickers; names come from rulebook/diets.json.tailwind.config.ts: design tokens from the pitch deck: washi cream, ai indigo, shu vermilion, moss, amber.
