A company-and-program pair forced MatchCard to take any subject

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. The third MatchCard hunt, staying in finance: a ⁠subsidy and grant matching screen⁠ (the company's own profile paired with subsidy programs, fit scores, requirement fit). A subsidy SaaS for small businesses.

Result: 3.5/5, with the two-party pairing missing throughout

tsc passed, and both mobile and desktop held up. From the agent (configured to have never touched Gunjo):

⁠The strong KPI, ranking, queue, and identity surfaces assembled fast from real components. But the core of the screen (the two-party match detail between the company and the program) has no component at all, and the one thing the catalog points to (RelationshipRow) is actively the wrong tool.⁠ The gap is expensive because it is the very reason this is a recommendation console.

The core observation: MatchCard shipped on sighting three, and company-to-program settled the spec

The match detail between the applicant company and a subsidy program (two subjects side by side, a fit score, requirement factors) got hand-rolled for the third time (MatchDetail.tsx, roughly 250 lines):

From the agent: "⁠There is no MatchCard, no PairingPanel, no two-party component for arbitrary subjects. RelationshipRow is the shape you want⁠ (left, a connector, relationshipLabel, right), ⁠but from and to are locked to PersonCellProps and render PersonCells on both sides. It assumes people, cannot be parameterized to a company and a program, does not even type-check, and has no score or factor area. There is no CompanyCell either, only PersonCell. Add a subject-agnostic MatchCard plus CompanyCell and this screen drops roughly 250 hand-rolled lines into plain assembly, going from 3.5 to 4.5 or higher.⁠"

⁠MatchCard reached three sightings: the freight-matching board in #160 (a load and an empty truck), the M&A pairing in #172 (a seller and a buyer), and the subsidy match here (a company and a program). I built it on the spot⁠, and this round turned out to be ⁠the deciding case⁠:

• #160 and #172 paired ⁠like with like⁠ (load and truck, company and company). ⁠This round paired a company with a program: two different kinds of subject.⁠ That is what ⁠proved⁠ MatchCard has to take arbitrary subjects, not people, not even companies.
• ⁠Two components shipped, as a linked pair⁠:
  • ⁠MatchCard⁠: left and right (any identity nodes, ⁠different kinds allowed⁠), a central score, factors[] (the requirement breakdown), and actions. A different animal from RelationshipRow (two fixed PersonCells, no score, no factors).
  • ⁠CompanyCell⁠: the organizational PersonCell (⁠a square logo⁠, a name, industry and location). Companies, programs, and counterparties stop being forced into a person's avatar and presence dot.
• ⁠The catalog was corrected too⁠: match and pairing entries point to MatchCard, organizational identity points to CompanyCell, and RelationshipRow is now marked people-only.
• In the browser I confirmed a MatchCard pairing Kyoei Seimitsu (a company) with the Monozukuri manufacturing subsidy (a program), holding ⁠two CompanyCells⁠ (the slots take any node; here both sides happened to fit CompanyCell), a 92% score, and the requirement factors: PR #430, closing issue #419. ⁠Components 25 and 26.⁠

What I took away: the third sighting is the one that finalizes the spec

Each of MatchCard's three sightings ⁠sharpened the spec⁠:

• #160, freight matching (load and truck, like kinds): "a two-party pairing is needed" (the gap discovered).
• #172, M&A (company and company, like kinds): "the people-locked RelationshipRow is wrong, and CompanyCell is needed too" (so it is not about people).
• This round, subsidies (company and program, ⁠unlike kinds⁠): "arbitrary, different kinds of subject" (the final spec).

Without this round's sighting, MatchCard might have shipped locked to a CompanyCell on each side. ⁠The company-and-program pair forced the decision to type left and right as plain ReactNode⁠, not CompanyCellProps. It is the mirror lesson of #172's RelationshipRow: type the slots too tightly (PersonCellProps) and the next unlike pair strands you. The third sighting in the rule of three is not a formality. It is ⁠the verification that locks the spec down⁠.

And CompanyCell shipped alongside: PersonCell for people, CompanyCell for organizations. ⁠"If there is a component for people, there needs to be one for organizations"⁠ (the organizational version of #150's "if there is display, there needs to be input").

What it flagged (solid)

• ✅ Leaderboard (the fit ranking), Meter (fit score, higher-is-better with a target), StatGroup, ActionQueue, FilterChips, and MetadataList all fit as-is: roughly eighty percent of the dashboard assembled fast.

⁠What changed under src this round: MatchCard plus CompanyCell (issue #419, PR #430).⁠ The score was 3.5/5, the two-party pairing became real components, subject-agnosticism was settled, and the catalog was corrected.

📊 Component scoreboard (⁠26 built⁠)

The newest three of the thirteen components and extensions added this session: DocumentRow / ⁠MatchCard / CompanyCell⁠. In progress: the candidate backlog is nearly dry, with only SimpleDialog at one sighting of three.

📋 Progress: the candidate backlog is nearly cleared

• All five transport modes complete ✅, and the deep dive turned goodWhen, OriginDestination, DocumentRow, MatchCard, and CompanyCell into components
• ⁠The backlog of three-sighting candidates is nearly exhausted⁠ (SimpleDialog at one of three remains). Next comes testing how the foundation holds in untouched industries.

Next up: build log #174

• ⁠A new industry⁠ (outside transport, accounting, and finance: energy, telecom, construction, medical, or the public sector), to see how the foundation holds on new ground and which new gaps appear. I'll make that call before #174 runs.

The run

• ⁠gunjo.jp⁠ / ⁠MatchCard⁠ (new) / ⁠CompanyCell⁠ (new) / ⁠Leaderboard⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #172
• ⁠GunjoUI by UIXHERO⁠

MatchCard became a component, and the company-and-program pair is what proved it had to take any subject. The third sighting in the rule of three is not bookkeeping; it is the verification that locks the spec.