content(ja): name the semantic-layer category セマンティックレイヤー, not the calque 意味層

[hotlong]

Fixes #159
Fixes #197

Japanese data-engineering writing names this category セマンティックレイヤー. 意味層 appears in that same writing as an inline gloss explaining the term — and a word used to explain the term is not the term. That matters for retrieval, which is what #78's tier-2 vocabulary exists for: セマンティックレイヤー is the string a Japanese reader would actually type.

Sweep — measured, not assumed, and now covering src/ as well as content/

grep -rn '意味層' src content scripts, and widened to the whole repo (minus node_modules / dist / .git) — both return the same set:

surface	before	after
content/blog/**/index.ja.mdx — frontmatter	3	0
content/blog/**/index.ja.mdx — body	15	0
src/components/ArticleList.astro — ja UI string	1	0
total 意味層 in the repository	19	0
total セマンティックレイヤー	0	19

Content side, per file — enterprise-ontology-race-open-vs-closed (fm 3, body 7), ai-ontology-open-protocol (body 5), why-ai-agent-pilots-fail-four-layers (body 3). The card named one file; the sweep found three, plus the UI string.

Name vs gloss: 19 names, 0 glosses

Every occurrence is the category used as a name; there are no glosses. Each was checked against its English source line, and all correspond to a literal "semantic layer" there (Looker semantic layer, three expose their semantic layer, a governed business semantic layer, ① Semantic layer, why the business semantic layer should be open). The seat verified this independently from the other direction by counting English siblings per file — en 5 / 9 / 3 against ja 5 / 9 / 3, one for one.

Since セマンティックレイヤー occurred zero times in the repo before this change, the 「セマンティックレイヤー（意味層）」 pattern the ruling protects did not exist anywhere, so the "leave the glosses" half had no instances to apply to. No gloss was minted either — the ruling said leave glosses, not create them.

src/components/ArticleList.astro:67 — the blog-index lead

The recommended-reading lead on /ja/blog/, the first Japanese prose a visitor to the site reads. Reported rather than edited in the first pass because it sits outside the file surface the ruling scoped; ruled in scope since, on evidence re-verified here:

locale	rendering of the same slot
en (line 49)	why the business semantic layer should be open
zh-Hans	业务语义层为什么该开放
zh-Hant	業務語意層為什麼該開放
de	warum die Business-Semantikschicht offen sein sollte
es	por qué la capa semántica de negocio debe ser abierta
fr	pourquoi la couche sémantique métier doit être ouverte
ko	비즈니스 시맨틱 레이어가 왜 열려 있어야 하는지
ja before	ビジネス意味層がなぜオープンであるべきか
ja after	ビジネスセマンティックレイヤーがなぜオープンであるべきか

The English sibling is the category used as a name — the same test that governed the other 18. Korean already used the transliteration. Japanese was the only calque in its own table.

Frontmatter title and description — confirmed by the seat

Flagged in the first round because the ruling named neither. Confirmed: keep them. #78 measured that tags are not routes here and rank nothing — three consumers, all unlinked — so if this card rests on retrieval, <title> / og:title / the meta description are the retrieval surface, and fixing the body while leaving 業務意味層 in the title would fix everything except the part that matters.

updated deliberately not set, also confirmed: AGENTS.md scopes it to a substantive revision — new sections, corrected claims, refreshed numbers — and rendering one term correctly is none of the three. topic / audience / date / status untouched; the slug is locale-independent, so no URL changes. Lint thresholds re-measured, no new warnings: title 28 → 36 chars (warn >95), description 112 → 120 (warn >230).

Diff is mechanical, with one declared exception

Every changed line was checked by re-applying 意味層 → セマンティックレイヤー to the removed line and comparing to the added line: 17 of 18 are a pure substitution, including the ArticleList.astro line. The one exception renders "semantic-layer tool" as セマンティックレイヤーのツール rather than the 13-kana run セマンティックレイヤーツール. Compounds follow each file's own established style: 業務セマンティックレイヤー (kanji + katakana, as in 業務プロセス) and ビジネスセマンティックレイヤー in the files that already write ビジネスオントロジー / ビジネスオブジェクト.

Deliberately left alone

• フォワードデプロイドエンジニア — per the ruling. The sweep turned up no contrary evidence: one file, one tag, a transliteration rather than a calque displacing a standard term.
• セマンティック層 (1 occurrence, body of give-your-agent-rules-for-governable-apps) — Japanese renders "semantic layer" as 意味層, a literal calque rather than the term the category uses #159 itself records this as acceptable field usage ("overwhelmingly uses セマンティックレイヤー (or セマンティック層)"), so it is not the calque this card rules on. Reported for the seat.
• zh-Hant — generated; untouched, and the clean tree after pnpm build proves it.

Gates

All five through the shared lock, each exit captured by redirecting to a file before any pipe, re-run after the patch commit on the merged tree at 901948b (origin/main c2b3171 merged in):

✓ content lint passed (335 files, 44 glossary terms checked)      # content:lint
✓ content lint passed (335 files, 44 glossary terms checked)      # content:lint --published
Result (135 files): - 0 errors - 0 warnings - 0 hints             # check
[build] 867 page(s) built in 34.98s / [build] Complete!           # build
SEO smoke test passed (866 HTML pages checked)                    # seo:smoke

os-verify-lock: VERDICT command-exit 0 · held the lock 48s · waited 0s; per-gate exits lint=0 lintpub=0 check=0 build=0 seo=0. git status --porcelain empty afterwards, which also proves the generated zh-Hant is untouched (pnpm build runs gen-zh-hant first). Control-byte scan of every edited file returned no hits. No changeset: this repo has no .changeset directory.

Browser pass — measured against a baseline build

For the first round I built origin/main (435ff61) in a second worktree, served both, and diffed identical measurements at 1440×900 and 390×844 across the post, two topic pages, the ja blog index and the ja glossary page. The patch round re-ran the same pass on the merged tree, with /ja/blog/ as a second explicit target.

No page-level horizontal overflow anywhere, at either width, before or after: documentElement.scrollWidth == clientWidth on every page. CLS 0.0000. Zero page errors.

What actually changed — this is what I saw, not an assertion that nothing moved:

	before	after
chip width (post, 1440)	53px	150px
post tag rows @1440	1	1
post tag rows @390	2	3 (ul 55px → 86px)
card facet rows @1440	3	4 (card 513px → 567px)
card chips @390	display:none	display:none (unchanged)
h1 height @1440	114px	170px (2 lines → 3)
/ja/blog/ lead @1440	2 lines (53px)	2 lines (53px)
/ja/blog/ lead @390	4 lines (106px)	5 lines (132px)

• The chip never clips (scrollWidth == clientWidth) and never escapes its container (chipRight 1174 < facetsRight 1235). Chips wrap onto a new row cleanly at both widths.
• On mobile card pages the tag chips compute display:none, so the widest-chip risk does not exist there at all — card height is identical at 390 (374px before and after). Measured, not inferred from the screenshot.
• The blog-index lead is flowing prose in a 358px column at 390 and grows by one line; not clipped (overflow: visible, scrollHeight == clientHeight), nothing escapes the column.
• Long words break mid-word in that lead at 390 — ビジネスセマンティックレイ / ヤー. That is browser-default CJK line-breaking and it is pre-existing on this exact paragraph: the baseline screenshot breaks オープ / ン in the same sentence. The change moves where it happens, not whether it happens. The post h1's 業 / 務 break at 1440 is the same story — the baseline breaks at exactly the same point.
• Cards in a grid row stay equal height, so the taller card does not misalign the row.

One correction to an earlier reading of mine, recorded because it nearly became a bogus finding. A first probe suggested the article's wide comparison table overflowed unscrollably at 390 — it measured the wrong element (the .prose wrapper). .prose table is itself the scroll container and works: display:block, overflow-x:auto, scrollWidth 1904 vs clientWidth 358, scrollLeft reaches 1546 (= 1904 − 358), page scrollWidth stays 390. The patch-round probe confirms it structurally — every past-viewport element on that page reports insideScroller: true. Unchanged by this PR either way, and no defect.

Screenshots reviewed at both widths for both builds and for the patch round.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01FeA1nwBz1ohH65dvffUGKr

[hotlong]

PATCH ROUND — one line, and the reason it is needed is another gap in my scoping.

The work itself is accepted and verified independently.

The sweep reproduces exactly. Across all 38 index.ja.mdx: 意味層 18 → 0, セマンティックレイヤー 0 → 18. Three files, no other locale touched, no updated line, 17 insertions / 17 deletions.

Your name-vs-gloss claim checks out from a direction you didn't use. You verified each occurrence against its English source line. I counted the English siblings independently:

post	en semantic layer	ja セマンティックレイヤー
ai-ontology-open-protocol	5	5
enterprise-ontology-race-open-vs-closed	9	9
why-ai-agent-pilots-fail-four-layers	3	3

One for one, per file. That is as close to proof as this gets: every Japanese occurrence corresponds to a literal semantic layer in the English, so all 18 are the category used as a name and there was never a gloss to preserve. Your point that the 「セマンティックレイヤー（意味層）」 pattern could not have existed — because セマンティックレイヤー occurred zero times before — is right, and declining to mint glosses was right too.

Ruling on the call you flagged: confirmed, keep title and description. My ruling named the tag and the body prose and did not name frontmatter, so you were right to raise it rather than assume. Your reasoning is better than my original scoping: #78 measured that tags are not routes here and rank nothing — three consumers, all unlinked. If this card rests on retrieval, then <title> and the meta description are the retrieval surface, and correcting the body while leaving 業務意味層 in the title would have fixed everything except the part that matters. Confirmed as shipped.

Ruling on updated: correctly not set, and don't add it. AGENTS.md is explicit — updated is for "a substantive revision — new sections, corrected claims, refreshed numbers. Not for a typo fix." Rendering one term correctly is none of the three: no claim changed, no number moved, no section appeared. #172 is open about three PRs that should have set it, and the distinction is exactly this one. The same call applies to #192's 435 substitutions.

What is missing — one line, in a file I never put on your surface.

src/components/ArticleList.astro:67
  recommendedLead: 'まずはここから：ビジネス意味層がなぜオープンであるべきか、…'

That is the recommended-reading lead on the Japanese blog index — the first Japanese prose a visitor reads on this site. It is the only 意味層 left in the repository, and it is the same term in the same wrong rendering.

Two things make it clearly in scope even though my ruling didn't name it. Its English sibling on line 49 reads "why the business semantic layer should be open" — so it is the same category used as a name, by the same test that governed your 18. And the Korean sibling on line 91 already reads 비즈니스 시맨틱 레이어 — the transliteration, not a calque. Japanese is the odd one out in its own table.

My claim comment scoped your file surface to content/blog/**/index.ja.mdx plus the vocabulary table, so you worked what you were given. This is the second time in this wave that my scoping stopped at content/ and missed a src/ UI string — the same thing happened on #192, which is in a patch round for it right now. That is a pattern in my dispatches, not in your work: this site's translated text lives in two places, and a terminology card has to cover both.

What to do:

1. Change that one line to ビジネスセマンティックレイヤー.
2. Sweep first, don't take my word for the count. grep -rn '意味層' src content scripts returned exactly one hit for me; confirm it, and if you find more, fix them and say so.
3. Re-run the five gates through the shared lock, exits captured before any pipe, verdicts quoted with git rev-parse --short HEAD.
4. The browser pass now has a second target: the Japanese blog index (/ja/blog/), where that lead renders, alongside the tag/topic page you were already checking. The chip-width concern still stands — 3 characters to 11 — and now so does a lead paragraph that got 8 characters longer. 1440×900 and 390×844, and say what you actually see rather than asserting no overflow.
5. Update the PR body's sweep table to cover src/ as well as content/.

On フォワードデプロイドエンジニア — unchanged, leave it, as ruled.

Serial constraints: #188 landed on main as c2b3171 and #190 as 5d4b0b6; neither touches your files. #192's patch round owns src/lib/zhconvert.ts, src/lib/terms.ts and the generator — src/components/ArticleList.astro is yours and does not collide.

---

Generated by Claude Code

[hotlong]

ACCEPT. The agent was killed by a container restart before it could report, so this is a review of the branch alone — 901948b was pushed first, which is why there is anything to review.

The sweep is now complete across both places this site keeps translated text.

	before	after
意味層 anywhere in the repo (src + content + scripts)	19	0
セマンティックレイヤー in content/blog/**/index.ja.mdx	0	18
…in src/	0	1
意味層 in built HTML	present	0 pages, 0 occurrences
セマンティックレイヤー in built HTML	0	56 occurrences, 12 pages

The Japanese blog index now leads with 「まずはここから：ビジネスセマンティックレイヤーがなぜオープンであるべきか…」, and the diff on ArticleList.astro touches only the ja line — the other seven locales in that table are byte-identical, which is what I wanted to check before landing a one-line edit in a shared component.

Union with current main (c2b3171 + #192 + this branch), all five gates through the shared lock: content:lint 0, content:lint --published 0, check 0, build 0 (867 page(s) built), seo:smoke 0 (866 HTML pages checked), tree clean.

Browser pass, and the width concern was the right thing to check. The chip went from 3 characters to 11 and the lead paragraph grew by 8, so the question was real. Four pages × two viewports (1440×900 and 390×844): page-level horizontal overflow 0px on all eight, 意味層 0 on every one. The Japanese post carrying the tag chips renders at 390 with no wrapping defect. (The thead/tr/th measured wider than the viewport at 390 are the article tables inside the overflow-x:auto container #157 gave a scroll affordance — the design, not a regression.)

Confirming both calls you raised, for the record:

• title and description stay in scope. My original ruling named only the tag and the body; your reasoning from Consolidate the blog tag vocabulary onto the tier-2 category terms #78's own measurement — tags are not routes here and rank nothing, so <title> and the meta description are the retrieval surface this card actually rests on — is better than my scoping was.
• updated correctly not set. AGENTS.md scopes it to "new sections, corrected claims, refreshed numbers"; rendering one term correctly is none of the three. The same call was applied to gen-zh-hant: ship 權限/實例 and the straddled locative 裡 #192's 435 substitutions.

And the thing you proved that I only asserted. I ruled from usage that 意味層 appears as a gloss rather than a name. You checked all 18 against their English source lines; I checked the count from the other side and got 5/9/3 English against 5/9/3 Japanese, one for one per file. Every occurrence corresponds to a literal semantic layer. There was no gloss to preserve, and declining to mint one was right — the ruling protected a pattern that did not exist yet, and inventing instances of it would have been editorial matter nobody asked for.

Landing on main.

---

Generated by Claude Code