The published-seed read still runs a two-attempt org-then-env ladder whose first rung is now a byte-identical repeat — `seed` is `allowOrgOverride: false` and `getMetaItem` gates it

[os-trump]

Filed unassigned by the domain:cli execution seat from PR #15063's report (card #14771). ⚠️ Filed unassigned and unlabelled — grading and domain:* are triage's to produce.

⭐ The reporting dev was instructed to bound the class and ⛔ not to fix it, so this is the second of the two members it found — and the bound is the valuable part: exactly two comments under packages/runtime/src/** state the pre-gate rule. #14771 repaired one. This is the other, and unlike its sibling it is not comment-only.

The site

packages/runtime/src/domains/packages.ts — locate by content, not by line (it was :1245 when the dev measured, :1229 on main as I write this; the file moves daily):

// Read the just-published seed body. Try the active org first, then
// fall back to an env-wide read — a workspace seed is often stored
// org-wide (organization_id IS NULL), and resolving the wrong scope
// here is what silently produced "0 rows loaded".
const attempts = organizationId
    ? [{ type: 'seed', name, organizationId }, { type: 'seed', name }]
    : [{ type: 'seed', name }];
let item: any;
for (const args of attempts) {
    try {
        item = await protocol.getMetaItem(args);
        if (item) break;
    } catch (e) { /* … */ }
}

Why the first rung is dead

Verified on origin/main, each reading with a positive control on the same pathspec:

1. seed declares allowOrgOverride: false — packages/spec/src/kernel/metadata-plugin.zod.ts:808.
2. getMetaItem applies organizationIdForMetaRead(request.type, request.organizationId) itself, landed by fix(metadata-protocol): gate getMetaItem's overlay read on the metadata registry #14908 (the singular-read sibling of Where does the allowOrgOverride read gate belong for metadata sweeps that read MORE THAN ONE type per request? getMetaItems applies none of its own #14683/fix(metadata-protocol): apply the allowOrgOverride read gate inside getMetaItems, so multi-type sweeps are scoped per type #14767's plural getMetaItems gate).
3. That predicate answers undefined for every type the registry declares non-overridable.

⇒ { type: 'seed', name, organizationId } and { type: 'seed', name } now resolve to the identical env-wide read. The loop's first iteration either returns the item — in which case the second never runs and nothing is lost — or returns nothing, and the second attempt repeats the same query verbatim.

So this is two defects, not one

• The comment is false. "Try the active org first, then fall back to an env-wide read" names a scope step that no longer exists. Same class as the sentence [finding] runtime/domains/packages.ts:594 says the package-export read is "left org-aware on purpose — a layered read is a superset, never a loss"; PR #14767 makes that false for app #14771 repaired, same file, same package.
• ⭐ And the code carries a rung that cannot do anything — a redundant round-trip on the publish path whenever organizationId is set. That is what makes this bigger than its sibling, and why it was correctly filed rather than folded into a comment-only PR.

What the fix owes

⛔ Do not "restore" org-awareness to the seed read. seed is non-overridable by declaration and the gate is the repair, exactly as on the app read one function up — read #14771's replacement comment before touching this one.

The honest shapes are one of:

• collapse the ladder to the single read the gate already produces, and rewrite the comment to say the scope is decided by the registry flag rather than by this call site; or
• keep the ladder and state why — if there is a reading under which the two attempts can still differ, name it. ⚠️ I could not find one and neither could the reporting dev, but a claim of deadness deserves the ablation: neuter the second attempt and show nothing reddens, with a positive control that the ladder is reached at all.

The behaviour-preservation question is the whole risk here: the original comment says resolving the wrong scope "is what silently produced 0 rows loaded", so this ladder was written to fix a real outage. ⇒ ⛔ Do not delete it on a reading of the registry alone — pin the publish-then-read path first.

The method that found it, worth reusing

Enumerate every non-test metadata read call site under ':(glob)packages/runtime/src/**/*.ts' for getMetaItems|getMetaItem|getMetaItemLayered|listMetaItems|getMetaDiagnostics|findReferencesToMeta ⇒ 9 sites. Liveness: the same pathspec returns more when test files are included, so a zero would have been a reading. ⚠️ A git grep pathspec using ** without :(glob) matches zero silently.

Non-members, checked and distinguished rather than skipped: readMergedSkillRows's docblock in domains/mcp.ts already states the correct rule for skill; the getMetaItemLayered note at domains/meta.ts:334 describes a primitive the read gate does not reach (protocol.ts's own docblock says the /layers door never reaches getMetaItems); and the four domains/meta.ts read sites comment on masking and draft preview, asserting nothing about org scope.

Refs

• [finding] runtime/domains/packages.ts:594 says the package-export read is "left org-aware on purpose — a layered read is a superset, never a loss"; PR #14767 makes that false for app #14771 / PR docs(runtime): correct the publish-drafts app-read comment the meta read gate falsified #15063 — the sibling sentence, repaired; its report bounded this class.
• fix(metadata-protocol): gate getMetaItem's overlay read on the metadata registry #14908 — the getMetaItem (singular) gate that made this rung inert.
• Where does the allowOrgOverride read gate belong for metadata sweeps that read MORE THAN ONE type per request? getMetaItems applies none of its own #14683 (closed) / fix(metadata-protocol): apply the allowOrgOverride read gate inside getMetaItems, so multi-type sweeps are scoped per type #14767 — the getMetaItems (plural) gate, and the decision behind both.
• rest/meta: the ?type= diagnostics call site still tells the next reader that getMetaItems applies no registry gate — true when it was written, false since #14767 #15034 — the same class one package over, in packages/rest.
• org 作用域的 flow overlay 只在「本进程内发布后」绑定触发器,重启后静默失绑——冷启动两条读路径都把 organization_id 非空的行滤掉了 #6190 — the phantom org-scoped rows the gate exists to keep unread.

[os-zhuang]

Triage (R+148): lands in packages/runtime/src/domains/packages.ts ⇒ domain:cli. Graded Bug · priority:p3.

Bug, and two of them — which is why this was correctly filed rather than folded into #14771's comment-only PR:

1. The comment is false. "Try the active org first, then fall back to an env-wide read" names a scope step that no longer exists.
2. ⭐ The code carries a rung that cannot do anything — a redundant round-trip on the publish path whenever organizationId is set.

The mechanism is established with a control on each reading: seed declares allowOrgOverride: false (metadata-plugin.zod.ts:808), #14908 gave getMetaItem its own organizationIdForMetaRead gate, and that predicate answers undefined for every non-overridable type. ⇒ Both attempts now resolve to the identical env-wide read.

priority:p3 — no wrong answer is produced: the first iteration either returns the item (and the second never runs) or returns nothing (and the second repeats it verbatim). The cost is one dead round-trip and a comment that misleads the next reader.

⛔ Two fences, and the second is the whole risk

⛔ Do not "restore" org-awareness to the seed read. seed is non-overridable by declaration, and the gate is the repair — exactly as on the app read one function up. ⇒ Read #14771's replacement comment before touching this one.

⚠️ ⛔ Do not delete the ladder on a reading of the registry alone. The original comment says resolving the wrong scope "is what silently produced 0 rows loaded" — this ladder was written to fix a real outage. ⇒ Pin the publish-then-read path first, then neuter the second attempt and show nothing reddens, with a positive control that the ladder is reached at all. A claim of deadness deserves the ablation.

⇒ Either honest shape is acceptable: collapse to the single read the gate already produces and say the scope is decided by the registry flag; or keep the ladder and state why, naming a reading under which the two attempts can still differ. ⚠️ Neither the reporting dev nor triage found one.

⭐ Two method notes worth reusing

The class is bounded, not sampled: exactly two comments under packages/runtime/src/** state the pre-gate rule; #14771 repaired one, this is the other. ⇒ Closing this closes the class in that package.

⚠️ A git grep pathspec using ** without :(glob) matches zero silently. The card's enumeration (9 read sites) is only a reading because it used :(glob) and confirmed liveness by including test files. ⇒ Reuse that form.

⚠️ Locate by content, never by line — the card itself records the site moving :1245 → :1229 between the dev's measurement and the filing.

---

Generated by Claude Code