refactor(views): retire the duplicate SIMPLE layout example from the lead showcase

[claude]

Closes #1707

Description

src/views/lead.view.ts opens by declaring itself a UI showcase — item 1 of
its own file header is "All 6 FormView layout types (simple, tabbed, wizard,
split, drawer, modal)" — and each entry in its formViews block carries a
numbered comment saying which layout it is the example of.

So "nothing can reach it" is not why quick_create goes. By that argument
most of its siblings would go with it: on the measurement below, no named form
view on crm_lead is reachable. Deleting one member of a self-declared showcase
because it is unreachable, while leaving the equally unreachable rest, is not a
cleanup — it is an unruled sweep, decided one entry at a time.

What makes quick_create different is written in its own comment:

/**
 * 1. SIMPLE Layout (already shown as default form above)
 * Basic sectioned form
 */

In a set whose organising principle is one example per layout, that is the
duplicate exhibit. The layout it demonstrates is demonstrated by the default
form, which declares type: 'simple'. Remove it and the showcase still
covers all six layout types; remove any sibling and it loses one — each of
detail_form (tabbed), lead_conversion_wizard (wizard), split_edit (split),
quick_edit_drawer (drawer) and status_update_modal (modal) is the only
example of its own.

Unreachability is why the removal is free, not why it happens. That
distinction is the whole content of this PR's ruling, and it is why this is not
a precedent for deleting anything else in the file.

Changes Made

• src/views/lead.view.ts — delete formViews.quick_create and its numbered
  comment. Nothing else in the file changes except the formViews block comment,
  which now states the organising principle (one example per layout, SIMPLE being
  the default form) so the next reader does not have to re-derive it. The shared
  DUPLICATE_LINK_FIELDS constant is untouched — quick_create was one of eight
  users. The default form is untouched; it already carries those eight fields
  and roughly twelve more.
• src/translations/{en,zh-CN,ja-JP,es-ES}/objects.pipeline.ts — drop
  crm_lead._sections.lead_details, the section heading whose only source was the
  deleted form. See the i18n measurement below.
• docs/feature-inventory.md — LEA-015 said "8 named forms"; it is 7.
• test/metadata-references.test.ts — a scope note used quick_create as its
  example of a named form that still carries a data block. It named a form that
  no longer exists; the example is now lead_conversion_wizard / split_edit,
  both of which do.

The last three are the same fact seen from elsewhere, not extra scope.

Measurements

1. Reachability, re-verified on the pinned 17.3.0 bundle

Against node_modules/@objectstack/console/dist/assets:

read site	expression
RecordFormPage-CGQlYWDk.js	H.form ?? H.formViews?.default ?? {}
useActionModal-CkM-zGdy.js	e?.form ?? e?.formViews?.default
RecordDetailView-A8bbPnkK.js	formViews?.default?.subforms
index-BU-FzlQ6.js	e.formViews[n] = i — a write, in the stored-view normalizer

No read is keyed by an authored name. crm_lead declares form, so form wins
and no named form view is consulted. Enumerating every .view property read in
the entire bundle returns exactly three, none of which resolves a form view.

One card premise did not survive this. #1707 listed navigation.view as the
one path that is reached, and concluded detail_form was live. It is not:
navigation.view is read once and passed as the second argument of onNavigate
— the navigation mode slot, whose consumer compares it against `edit`
and `view`. Filed as #1716 rather than fixed here: different key,
different blast radius, and telling "inert" from "row click does nothing" needs
a browser.

This does not move the ruling, because the ruling never rested on reachability.
And it triggers no widening: the stop-and-report condition was a sibling that is
both unreachable and a duplicate layout example. None is. web_to_lead and
advanced_conditional are also type: 'simple', but neither is a numbered
layout slot — they are the file's only examples of public/anonymous sharing and
of conditional field visibility respectively, which are items 2 and 3 of the
file's own showcase list.

2. i18n orphan keys — the difference set is four, and it is not empty

Deleting the form deletes the source of its section name lead_details, whose
only other occurrence in src/ is a record:details component id on the
detail page — a different keyspace (pages.*.components.*, which declares no
lead_details), not a section name.

Measured by running objectstack lint --json on the tree at HEAD and again
with only the form deleted:

	issues	warnings	passed
baseline (HEAD)	13	1	true
form deleted, locale keys kept	17	5	true
this PR (keys removed too)	13	1	true

The four introduced were exactly one per locale:

translation-target-unknown  translations[0].en.objects.crm_lead._sections.lead_details
translation-target-unknown  translations[0]["zh-CN"].objects.crm_lead._sections.lead_details
translation-target-unknown  translations[0]["ja-JP"].objects.crm_lead._sections.lead_details
translation-target-unknown  translations[0]["es-ES"].objects.crm_lead._sections.lead_details

#1262's warning holds, and its wording needs one correction. pnpm verify
stays green with those four dead keys in the tree — passed: true, lint exits 0
on warnings, and check-lint-i18n-gate.mjs gates only on i18n/missing-*, which
translation-target-unknown is not. So green is indeed no evidence of no
orphans, exactly as #1262 says. But the check itself is not absent: the
platform's own lint reports each one by path and even suggests the fix ("or drop
the translation"). #1262's claim that orphaned keys are "invisible to every i18n
check" is too strong for this surface — they are visible, and ungated. Worth a
line on that card; it changes the shape of the fix from "write a new check" to
"gate the one that exists".

They are removed here rather than reported and left, on this repo's own
precedent: #1262 records that PR #1261 removed its four orphans by hand for the
same reason. Removing them cannot change a rendered surface — lint's own message
is that the heading "stays in the source locale", i.e. the key resolves nothing —
and had the deletion been wrong, the surface-to-translation direction of
test/i18n-references.test.ts would have gone red. It did not.

3. Pin surface — checked before editing, not after

test/ walks formViews in five places, all generically. None names
quick_create, and no assertion pins a form-view count or name list. The
"guards the guard" floors are forms.length and offersReason.length greater
than 3; the lead form family goes 9 to 8 and the disqualification subset 8 to
7. No pin was relaxed, and none went red — 3408 tests pass.

4. Docs surface — swept by behaviour, not by token

Searching the token quick_create finds five decoys and one hit that matters:
the four locale pages.sales_home_page.components.quick_create keys and
src/pages/home.page.ts are the home page's Quick Create card, an unrelated
page:card that stays. Searching by behaviour instead (快速新建, 线索表单,
"quick capture", "8 fields", and the same in the other locales) found the one
piece of prose that this change falsifies: docs/feature-inventory.md LEA-015,
which counts the family. That row is corrected here.

Three other "quick-create" mentions (lead.object.ts, task.object.ts,
event.object.ts, event_attendee.view.ts) describe the console's generic
create dialog, not this form view, and are left alone.

Separately, all four locale bundles carry a comment claiming crm_lead has "six
named formViews". It had eight before this change and has seven after — wrong on
both sides, so it is pre-existing drift this PR did not create and does not fix.
Filed as #1717.

5. Neither in-flight surface is touched

No file in this diff belongs to #1214 item 4 (the quote family — crm_quote
translations live in objects.commerce.ts, not the objects.pipeline.ts this
PR edits) or to #1692 (src/data/sales.seed.ts).

6. Token ratchet

Removal only widens headroom, as expected — the numbers, not the assumption:

layer	before	after	headroom before	headroom after
business semantics	~84,483	~84,483	~15,517	~15,517
interaction layer	~37,958	~37,750	~2,042	~2,250
authored total	~136,782	~136,574	~3,218	~3,426

The measure is comment-stripped, so the added block comment costs nothing and the
locale edits are outside the ratchet by ruling.

Changeset: patch, derived from this repo's own removals

Level was chosen by counting, not by feel. Of 206 changesets, 111 declare
'hotcrm': patch, 7 minor, and 88 use the sanctioned empty frontmatter. Eight
of them open with Remove / Retire / Delete / Drop:

level	changeset	what it removed
minor	remove-knowledge-review-queue-tab	a tab the user could see
minor	remove-product-default-tax-rate	a field on the product catalog
patch	a-tab-is-a-view	list.tabs[] — view keys the console does not read
patch	tab-labels-live-on-the-view	tabs[].label, for the same reason
patch	csat-was-declared-never-enforced	#1428's two fields, reachable from no screen
patch	product-rows-name-what-the-catalog-has	inventory rows
patch	analytics-docs-drop-the-dataset-inventory	doc inventory
patch	retire-stackblitz-and-the-npm-lockfile	a demo and a lockfile

The split is by visible surface, not by diff size: the two minor removals
each took something off a screen; every patch removal took away metadata no
screen rendered — including #1428, which removed two fields, a flow, four
locales' labels and three doc locales' prose and still took patch.

This change removes metadata no screen rendered, so: patch. The empty
frontmatter form was not used because that one is for PRs that ship nothing
(test/ header notes, prose), and this one changes src/ metadata that ships in
the built artifact.

Testing

pnpm verify ran to completion with exit code 0. Each stage's real result, read
from the log rather than assumed:

stage	result
validate	✓ Validation passed (1325ms)
typecheck	tsc --noEmit, no diagnostics
lint	1 warning(s), 12 suggestion(s) — the pre-change count, unchanged
lint:i18n-gate	✓ i18n lint gate: 0 i18n/missing-* issues (13 total lint issue(s) reported)
hygiene	✓ source hygiene clean
hygiene:tokens	✓ source token ratchet clean (three ceilings green)
build	Artifact: dist/objectstack.json (1906.0 KB)
test	Test Files 161 passed (161) · Tests 3408 passed, 1 skipped (3409)

The lint row is the one worth reading twice: the count returns to the
pre-change 13, which is the evidence that this change leaves no orphaned key
behind rather than merely passing a gate that cannot see them.

Acceptance

• The showcase still covers all six layout types. SIMPLE via the default
  form (and web_to_lead / advanced_conditional); tabbed, wizard, split,
  drawer and modal each still have their sole example.
• No user-visible surface changes at all — no form, field, label or route.
  This is the half that separates this card from Retire crm_case.customer_rating / customer_feedback under ADR-0049, and retire or rewrite case_csat_followup with them (ruled A, 2026-09-03; the internal_notes half landed in PR #1506) #1428, where the removal did
  cost visible capability and went to the maintainer.

Out of scope, filed rather than ridden along

• [finding] crm_lead list navigation.view: 'detail_form' is not a form-view name to console 17.3.0 — it lands in the navigation MODE slot #1716 — crm_lead list navigation.view: 'detail_form' is read as a
  navigation mode, not a form-view name.
• [finding] The four locale bundles say crm_lead has "six named formViews" — it has seven, and had eight #1717 — the four locale bundles' "six named formViews" comment.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 6, 2026 1:08pm UTC