The docs catalog suggested giving a company an avatar

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. This round went hunting for MatchCard's next sighting in a new industry (M&A and business succession, finance): an ⁠M&A matching console⁠ (buyer and seller pairing, fit scores, and fit across industry, area, and size). A dense console for M&A advisors.

Result: 4/5, with only the pairing detail missing

tsc passed and the desktop layout held its density. From the agent (configured to have never touched Gunjo):

⁠A genuinely strong staff-facing library.⁠ The KPI band, the ranked-candidate list, the score Meter, the deal table, and the action queue each snapped onto a component built for exactly that use. The one dropped point is the single thing a matching console is ⁠about⁠: the two-party pairing detail. There is no company-to-company component, and the catalog actively misdirected toward the person-shaped one.

The core observation: the catalog recommended an avatar for a company (MatchCard at two of three)

The seller-and-buyer match detail (two companies side by side, a fit score, and factor fit across industry, area, size, price, and synergy) begs for RelationshipRow. But:

From the agent: "⁠There is no two-party MatchCard or PairingPanel, so I hand-rolled one (PairingPanel.tsx). There is no identity cell for a company either: PersonCell is avatar plus name plus role, so I built the company column from scratch. For 'place two people side by side (a manager and a report)' the catalog steers you to RelationshipRow, but RelationshipRow's from and to are typed as PersonCellProps and render two PersonCells (an avatar and a presence dot). For company-to-company that is wrong on three counts: (1) it forces a person's avatar-and-presence model onto an organization, (2) it has no slot for each company's list of financials, and (3) it has no area for a score or a factor breakdown (only the thin relationshipLabel). The catalog recommends the visually nearest thing while being semantically wrong. What should be added is a generic two-party MatchCard or PairingPanel (left and right subjects plus score and factors, with no person assumption) and a CompanyCell (the organizational counterpart of PersonCell).⁠"

⁠MatchCard now stands at two of three: the freight-matching board in #160 (a load paired with an empty truck) and the M&A pairing here (a seller and a buyer).⁠ The spec has stayed stable across both sightings: slots for any left and right subject, a central score or connector, and a factors breakdown, none of it tied to what the subjects are. ⁠An attendant gap surfaced as well: CompanyCell⁠ (organizational identity: a logo or initials, a name, data), which is also the reason RelationshipRow is stuck on people. One more matching or comparison screen makes three sightings, and then it gets built.

What I took away: visually close and semantically right are different things

I have been sorting the catalog's traps into families (hiding, substituting on type, accessibility, or layout form, and self-admitted mismatches). This round's RelationshipRow case is the substitution trap in its most textbook form:

• ⁠Visually, it is close⁠ (a wide component that places two parties side by side).
• ⁠Semantically, it is backwards⁠ (locked to people, with no room for company financials or a fit score).

The agent's phrasing was exact: the catalog recommends the visually nearest thing while being semantically wrong, and it happens on the pairing detail that a matching console is ⁠about⁠. This sits one step past the form mix-up in #170 (horizontal versus vertical): ⁠here the shape matches while the inner model (a person versus an organization) does not.⁠ Catalog grading has to cover the subject model, on top of type, accessibility, and layout form.

When the third sighting arrives, MatchCard gets built with no person assumption, and CompanyCell gets built at the same time: PersonCell for people, CompanyCell for organizations, a pair. ⁠A people component implies an organization component.⁠ That is the rule from #150 (display implies input), replayed for organizations.

What it flagged (solid, verified in a new industry)

• ✅ Leaderboard (the fit ranking), DataTable (the deal list), Meter (fit score, higher-is-better with a target marking the recommendation line), ActionQueue (NDAs and pending replies), StatGroup, FilterChips, and MetadataList (each company's financials) all fit as-is.
• 🟡 Only Select is children-and-option driven, out of step with the items-prop convention everywhere else (a developer-experience nit), and the tone unions of Badge and Tag are incompatible with Meter and Leaderboard's, so mapping glue is needed.

⁠No new src component this round⁠ (4/5, MatchCard at two of three, RelationshipRow's people lock reconfirmed, CompanyCell surfaced).

📊 Component scoreboard (⁠24 built⁠)

The newest two of the eleven components and extensions added this session: OriginDestination / DocumentRow. In progress: ⁠MatchCard at two of three⁠, CompanyCell at one of three, and SimpleDialog at one of three.

📋 Progress

• All five transport modes complete ✅, and the candidate-backlog deep dive turned goodWhen, OriginDestination, and DocumentRow into components
• MatchCard at two of three (one sighting short of a build), and a first screen in a new industry, finance (M&A)

Next up: build log #173

• A third MatchCard sighting (another matching or comparison screen) leading to a build plus CompanyCell, or deeper into new industries. I'll decide before the next round.

The run

• ⁠gunjo.jp⁠ / ⁠Leaderboard⁠ / ⁠Meter⁠ / ⁠ActionDataTable⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #171
• ⁠GunjoUI by UIXHERO⁠

The catalog suggested an avatar for a company: visually close, semantically backwards (a person versus an organization). Catalog grading must include the subject model. MatchCard will be built with no person assumption, paired with CompanyCell.