[Decision] Generated non-`objects` i18n groups carry no provenance from EITHER mechanism — `--no-objects-only` fills leaves from source that no predicate judges

[os-project-manager]

Origin: measured by the implementing seat while delivering #16242 (PR #16871), and deliberately not acted on there — it changes which predicate judges an apps leaf and interacts with a hand-maintained file, so it is a decision rather than a mechanical follow-up. The delivering seat recommended the dispatching seat file it; this is that filing. Not claimed, no assignee.

⭐ This is the real form of #16242's HARM statement. That card asserted a harm and attributed it to a narrowing step. The narrowing mechanism was falsified during delivery (premise_still_valid: false) — but the harm it described turned out to exist, by a different route. Recording it so the true mechanism does not get closed along with the false one.

Measured

--no-objects-only makes the stack module emit apps.* leaves into a .generated.ts file, and --fill=default fills them from the source locale — leaves with exactly the property the generated-leaf predicate exists to judge.

They get no record from either mechanism:

mechanism	why it skips them
findStaleFills / the generated companion	its population is GENERATED_SECTIONS, and that is ['objects', 'metadataForms'] — read at packages/platform-objects/src/apps/translations/source-hash.ts:178. An apps.* leaf is not in it.
the hand-authored LOCALE.source-hashes.ts	has no entry for a generated leaf.

Re-derived by the dispatching seat at origin/main c930f85971, with a negative control that returned empty on a false spelling:

packages/platform-objects/src/apps/translations/source-hash.ts:178
    export const GENERATED_SECTIONS = ['objects', 'metadataForms'] as const;
packages/platform-objects/src/apps/translations/source-hash.ts:250
    return collectLeavesOf(data, GENERATED_SECTIONS);
packages/cli/src/utils/i18n-extract.ts:1848
    sourceHashes[locale] = collectFilledFromHashes(…)

Measured on the delivering seat's fixtures: the unnarrowed provenance table holds 775 records — 2 objects.* + 773 metadataForms.*, and apps.kpi.label is absent from it.

⇒ A generated apps leaf that has drifted from its source serves the superseded draft, and nothing on disk records that it might have.

Why it is dormant today, and why that is not a reason to close it

The repo's one --source-hashes config runs under the default --objects-only, so no apps.* leaf is emitted into that path today. ⚠️ The gap is therefore latent, not active — but it is armed by a flag a user can pass, and the failure is silent: the leaf is served, not refused.

The decision

⛔ Not this seat's, and not the delivering seat's — it selects the population a predicate judges.

• A — add the emitted stack groups to GENERATED_SECTIONS, so generated apps/dashboards leaves are judged by findStaleFills like objects leaves.
• B — leave the split and document that --no-objects-only emits leaves with no staleness coverage, written where a reader would look rather than in a flag description.
• C — decide that --no-objects-only should not fill non-objects groups from source at all, removing the population instead of covering it.

The delivering seat recommends A, with an argument this seat finds sound and relays rather than endorses: the predicate should follow how the leaf got there — copied from source by --fill=default — rather than which section name it sits under.

⭐ It has in-repo support: source-hash.ts:111 already carries a module note arguing for extending the mechanism to the generated bundles. ⚠️ Against A: it interacts with the hand-maintained LOCALE.source-hashes.ts, which is the part that makes it a decision.

Relationship to the two closed neighbours — different axis, not a duplicate

Both closed cards in this family measure a bundle-set axis. This one measures a section axis, inside the one covered set.

• [finding] Generated-leaf staleness detection covers 1 of 9 i18n bundle sets — the other 8 stay legacy-trusted, and nothing says so at the point a reader would look #12559 — which of the 9 bundle sets opt in to --source-hashes (1 of 9 at the time). Closed.
• [finding] The generated-leaf provenance companion is now RECORDED in 9 of 9 bundle sets and READ at serving time in 1 — withSourceFallback was never wired outside platform-objects #12642 — where withSourceFallback is wired at serving time (1 of 9 sets). Closed.
• This card — within a set that is covered and does serve provenance, which sections the predicate's population contains. GENERATED_SECTIONS names two; --no-objects-only emits a third kind.

⇒ Covering every set (#12559) and wiring every set (#12642) would both leave this gap exactly where it is.

Dedupe

Two queries, both with the positive control firing in the same session.

• "GENERATED_SECTIONS provenance generated leaves staleness coverage source-hashes" → 2 hits, both closed: [finding] The generated-leaf provenance companion is now RECORDED in 9 of 9 bundle sets and READ at serving time in 1 — withSourceFallback was never wired outside platform-objects #12642, [finding] Generated-leaf staleness detection covers 1 of 9 i18n bundle sets — the other 8 stay legacy-trusted, and nothing says so at the point a reader would look #12559. ⭐ Control: the query resolves this exact vocabulary and returns the [finding] check:i18n verifies key presence, not that an untranslated leaf still matches the source string it was filled from — and the drift is sticky #11671/[Decision] 把 #8765 的 source-hash sidecar 扩展到生成的 i18n bundle —— #9672 写明的升级条件已满足 #12069 family, so the absence of a section-axis card is a reading, not a channel outage.
• "i18n extract source-hashes provenance companion sections" → 6 hits: cli: os i18n extract --no-objects-only --source-hashes drops every non-objects provenance record — the committed-section list is the literal 'objects', not the sections the module holds #16242 (this card's origin), i18n: the extractor omits an id key translatePage reads and PREFERS — region-level page:header carrying an id (the second half of the #13109 pair) #16147, i18n-extract scaffolds none of the three key families #14253 adds, so check:i18n-coverage is blind to them #14376, [Decision] 把 #8765 的 source-hash sidecar 扩展到生成的 i18n bundle —— #9672 写明的升级条件已满足 #12069 (the ruling), [finding] The generated-leaf provenance companion is now RECORDED in 9 of 9 bundle sets and READ at serving time in 1 — withSourceFallback was never wired outside platform-objects #12642, i18n: extract + gate declared action/UI labels (they leak English in a zh-CN workspace) #3370 — every one either the set axis, the ruling, or an unrelated extractor defect.

⇒ No duplicate on the section axis.

Grading

⛔ Filed unlabelled. domain:*, type and priority are triage's, not this seat's. Relayed as a suggestion only: domain:cli, and the delivering seat's own reading that this is dormant today ⇒ low urgency, but a decision rather than a task, because option C would remove behaviour rather than add coverage.

Refs: #16242 (origin, PR #16871), #12559, #12642, #12069 (maintainer ruling on the mechanism), #11671.