The E3 standard needs three written `published` boundaries — `.js.map` sourcesContent, `@objectstack/spec`’s shipped `src/**/*.zod.ts`, and whether it reaches a defect the round did not cause

[claude]

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. ⛔ Not a request to change the ruling: the E3 standard is the maintainer's and this card asks it three questions, ⛔ it does not answer them. Filed by the domain:engine dispatching seat because the questions have been carried in a session's working notes across several rounds with no carrier, and working notes are not a durable record.

The ruling this is about

E3 standard ruling, maintainer, 2026-09-05: 「已发布必修,其余立卡」 — a defect on a published surface is fixed in-round; non-published residue is carded and the PR lands. Its power comes from 「published」 being a measurement rather than a judgement: against built dist/**/*.d.ts, dist/**/*.{js,mjs,cjs} and content/docs/**.

⭐ That is exactly why it works, and exactly why the three cases below need answers in writing: each is a place where two seats reading the same ruling honestly can measure different things.

Question 1 — is a .js.map's sourcesContent published?

A source map ships in dist/. sourcesContent embeds the original source text inside it. So a defect in a comment or a docstring that never reaches .d.ts or .js still reaches a consumer who opens the map.

⚠️ NOT re-measured by this seat. It was read in an earlier round and is recorded here as an inherited claim, ⛔ not as a reading. Whoever answers should measure rather than inherit:

pnpm --filter @objectstack/spec build
node -e 'const j=require("./packages/spec/dist/index.js.map");console.log(Array.isArray(j.sourcesContent), (j.sourcesContent||[]).length)'

⭐ The reason it matters is a round already turned on it: a review argued that a reading which put sourcesContent inside 「published」 would sweep essentially every comment in the repo into the must-fix-in-round class — 「a reading that empties the category the ruling created cannot be the ruling's meaning」. That argument is persuasive but it is an argument, ⛔ not a ruling.

Question 2 — @objectstack/spec ships its Zod source, and that is measured

⭐ Unlike question 1, this one is settled as a fact and only its consequence is open. packages/spec/package.json, files[], verbatim from origin/main:

["dist","json-schema","liveness","prompts","llms.txt","README.md","src/**/*.zod.ts","CHANGELOG.md","api-surface","spec-changes.json"]

⇒ src/**/*.zod.ts is in the published tarball. Every TSDoc, every inline comment and every .describe() string in those files reaches a consumer who opens node_modules/@objectstack/spec/src/….

But the E3 measurement as written names dist/**/*.d.ts, dist/**/*.{js,mjs,cjs} and content/docs/** — and ⛔ src/**/*.zod.ts is in none of those globs. So a seat that runs the ruling's own instrument literally will read a false docstring in a shipped .zod.ts as not published, and card it. A seat that reasons from files[] will read it as published, and must fix it in-round. Both are acting in good faith on the same ruling.

Question 3 — does 「已发布必修」 reach a defect the round did not cause?

⭐ This one is not hypothetical; it arrived with a concrete case today.

While delivering #14238 (two new timezone columns), the seat measured that two other platform objects already carry divergent timezone columns — sys_job (maxLength: 100, no default) and sys_report_schedule (maxLength: 64, defaultValue: 'UTC'), neither declaring valueDomain — and that they are published (packages/platform-objects/dist/audit/index.js ×2, index.d.ts ×3, measured). The ruling that scoped #14238 named two different objects and forbade widening.

So: a published defect, noticed by the round, not caused by it, on files the diff does not touch. 「已发布必修」 read plainly says fix it. The scoping ruling says do not.

This seat decided the concrete case — A, keep it carded (#15872) — on the ground that narrowing sys_job.timezone from 100 to 64 could refuse an already-stored value and nobody measured what that column holds, so 「fix it in-round」 cannot mean 「ship an unmeasured narrowing of a published bound」. The contract reviewer, independently and without being shown that reasoning, reached the same disposition. ⚠️ Convergence is not proof — two readers can share a wrong premise — but it does locate the ambiguity in the ruling's text rather than in one seat's reading.

The question, phrased so it can be answered once and reused:

Does 「已发布必修」 reach a published defect the round noticed but did not cause and does not touch, or only one the round's own change makes false?

What an answer would be worth

Each of the three is currently decided per-round, by whoever is holding it, in a comment nobody will find later. ⭐ A written boundary is worth more than a correct one-off decision, because the failure mode here is silent: a seat that measures 「not published」 cards a defect and lands, and nothing ever reports that the ruling would have said otherwise.

⛔ What is not claimed

⛔ Not that any of the three has a right answer this seat knows. ⛔ Not that the ruling is defective — it is doing real work, and the reason these questions exist at all is that it made 「published」 measurable enough for the edges to become visible. ⛔ No grade, no priority, no domain.

Related

#15872 (the concrete case behind question 3) · #14238 / PR #15874 (the round that raised it, and where the disposition is recorded at 5551751950 and 5551859701) · #15395 / card #14147 (the round where question 1's argument was made).

Dedup: ⚠️ /search/issues answers 403 in this container and an empty search is not a reading — this was a repo-scoped REST list of open issues. No open card carries the E3 boundary questions.

---

Generated by Claude Code

[claude]

Question 1, measured: is a published .js.map's sourcesContent a published surface?

This settles the fact for Question 1 only. The card records Q1 as an inherited claim explicitly marked NOT re-measured; it is now measured. ⛔ No disposition and no recommendation on the ruling — what the fact means for 「已发布必修」 is the maintainer's.

Bottom line, both limbs: the maps SHIP, and sourcesContent IS populated in the shipped ones — for every publishable package except the two named in Reading 1. Confirmed not only against a local dist/ and a --dry-run listing but against the tarballs npm is serving right now.

Measured at ea03c7c16 in a dedicated worktree, nothing edited (git diff --stat empty). Build ran through the shared lock: os-verify-lock: VERDICT command-exit 0 · held the lock 247s, 57 successful, 57 total. 57 publishable packages ended with a built dist/.

---

Reading 1 — is sourcesContent populated, and in which maps?

Survey over every .map under every built publishable dist/ (EXIT_R1FULL=0):

PUBLISHABLE PACKAGES WITH dist/ BUILT HERE: 57
  packages emitting >=1 .map: 56  | emitting none: 1 -> create-objectstack
  JS-ish .map files: 338 | empty sources[] (nothing to embed): 11 | with >=1 source: 327
     of those, sourcesContent POPULATED: 200
  .d.ts.map files: 122 | sourcesContent populated: 0

The class is split, and the split follows the build tool:

arm	packages	maps	sourcesContent
tsup / esbuild	55	205 js-ish maps with real sources	200 populated
tsc (@objectstack/cli)	1	122 js maps + 122 .d.ts.map	0 — field absent
no maps (create-objectstack)	1	0	n/a

The 5 tsup maps that are not populated are not stripped — they are generated re-export shims (276–281 bytes of CJS interop glue) whose sources names the emitted file itself, not a source file. There is no original text to embed. Example: packages/metadata-protocol/dist/build-probes-GJMTRHXD.cjs.map, sources = the emitted .cjs next to it.

Firing positive control for the zero (EXIT_R1B=0) — absence shown beside fields that are present in the same file, and beside a populated map from the same run:

packages/cli/dist/index.js.map
   keys=[version,file,sourceRoot,sources,names,mappings]
   sources=1  sourcesContent=ABSENT  mappings.len=2282
packages/spec/dist/index.js.map
   keys=[version,sources,names,mappings,file,sourcesContent]
   sources=110  sourcesContent=array len 110  mappings.len=775508

@objectstack/cli's zero is a real absence, not a read failure: sources and mappings parse fine in the same file.

Reading 2 — do the maps SHIP? (the limb the card's command does not touch)

Yes. Every map emitted into dist/ ships. Zero attrition.

• files[] census (EXIT_CENSUS=0): 69 publishable workspace packages. 68 declare exactly ["dist","README.md","CHANGELOG.md"]; only @objectstack/spec differs, and it differs by adding entries. dist is a bare directory entry — no extension filter, so .map is admitted by default.
• No .npmignore anywhere in the repo (EXIT_NPMIGNORE_LS=2, no such file).
• npm pack --dry-run --json over all 57 built publishable packages, every pack exit 0 (EXIT_SWEEPSUM=0):

  packages whose TARBALL CONTAINS >=1 .map: 56 of 57
  (the one without: create-objectstack, which emits none)
  .js/.mjs/.cjs .map in tarballs: 338      == identical to the on-disk dist count
  .d.ts.map in tarballs:          122      == identical to the on-disk dist count
  total map bytes: 196,466,298 of 398,316,339 unpacked = 49.3%

Maps are 49.3% of everything these 57 packages ship, by unpacked bytes.

• Tie-check that the listed entry is the file I measured (EXIT_TIE=0): @objectstack/spec dist/index.js.map — tarball size 4938676, on-disk size 4938676.
• The shipped .js reaches the map: packages/spec/dist/index.js, packages/core/dist/index.js, packages/cli/dist/index.js, packages/types/dist/index.js all end with sourceMappingURL=index.js.map. Not orphaned files.
• Publish pipeline strips nothing: scripts/release-publish.sh has no map handling; scripts/publish-smoke-pack.mjs's only .map hits are JavaScript Array.map() calls. No OS_SKIP_DTS or divergent build env in the release workflows — CI builds through the same turbo run build.

Registry confirmation — not a dry-run, the bytes npm actually serves:

npm pack @objectstack/types            EXIT_REGPACK=0
npm pack @objectstack/cli              EXIT_REGPACK_CLI=0
npm pack @objectstack/spec@17.3.0      EXIT_REGPACK_SPEC=0   (48,965,153 byte tarball)

published tarball	.map files served	populated sourcesContent
@objectstack/spec@17.3.0	44	44
@objectstack/types@17.3.0	4	4
@objectstack/cli	238	0

@objectstack/cli ships 238 maps that carry no source text, and its sources entries point at ../src/index.ts while src/ is absent from its tarball — 238 dead references.

Reading 3 — what is actually in it?

The full original source, verbatim, comments included. Audit of embedded text against the on-disk source (EXIT_R3C=0):

packages/spec/dist/index.js.map                 byte-identical=47  differ ONLY by /* @__PURE__ */=63  differ otherwise=0
packages/core/dist/index.js.map                 byte-identical=60                                     differ otherwise=0
packages/types/dist/index.js.map                byte-identical=17                                     differ otherwise=0
packages/platform-objects/dist/audit/index.js.map  byte-identical=10                                  differ otherwise=0

differ otherwise = 0 everywhere. @objectstack/spec is the only one with any delta, and the whole delta is the /* @__PURE__ */ annotation its pureSchemaConstruction esbuild plugin injects — removing that one token from the embedded text restores byte-equality with the source file exactly (EXIT_R3B=0). Nothing is stripped: no comment, no docstring, no .describe() string.

Verbatim, recovered from inside the tarball npm is serving for @objectstack/types@17.3.0, package/dist/index.js.map (EXIT_TAR_REG=0):

/**
 * Internal: clear the dedupe set. Test-only; exposed so suite-wide
 * deprecation warnings don't bleed between tests.
 *
 * @internal
 */

A block marked @internal and "Test-only" is fully readable by any consumer. And from published @objectstack/spec@17.3.0, package/dist/index.js.map, source ../src/shared/identifiers.zod.ts:

// Copyright (c) 2025 ObjectStack. Licensed under the Apache-2.0 license.

import { z } from 'zod';

/**
 * System Identifier Schema
 *
 * A lowercase machine-identifier grammar: starts with a letter, then letters,
 * digits, underscores or dots. ...

Reading 4 — is emission deliberate? (read from config, not inferred from output)

Map emission: deliberate and explicit. Source embedding: never configured — a toolchain default riding along.

• sourcemap: true is set explicitly in the root tsup.config.ts and in 19 per-package tsup.config.ts files (@objectstack/spec sets it twice, once for its main pass and once for its browser pass).
• packages/cli/tsconfig.build.json sets "sourceMap": true and "declarationMap": true.
• create-objectstack/tsup.config.ts has no sourcemap key — tsup's default is off, and it emits and ships zero maps. Config predicts output exactly, in both directions.
• sourcesContent is configured nowhere. git grep sourcesContent outside dist/ returns exactly one hit and it is CHANGELOG prose, not config (EXIT_G1=0). git grep inlineSources returns two hits, both an unrelated local variable in scripts/check-self-test-wired.mjs (EXIT_G2=0).

⇒ The split in Reading 1 is entirely the two toolchains' opposite defaults for an option neither config sets: esbuild embeds source text by default when sourcemap is on; tsc does not embed without inlineSources. Whoever set sourcemap: true chose to ship maps; nobody appears to have made a recorded choice about shipping the source text inside them.

A prior in-repo record of this exact fact (found while measuring, not sought)

packages/spec/CHANGELOG.md — in a published changeset, so this text itself ships:

Why this publishes at all: liveness/** is in this package's files, and the registry.ts docblock ships inside dist/*.map sourcesContent, so both edited byte-ranges are in the tarball.

The repo has already reasoned exactly this way once, and shipped the reasoning. That was a claim; the measurements above are an independent confirmation of it.

Scale — so the contract-review argument can be weighed against numbers

The strongest argument on the record is that putting sourcesContent inside 「published」 would sweep 「essentially every comment in the repo」 into the must-fix-in-round class. That is an argument about size, so here is the size. Across all 57 built publishable packages, de-duplicated (the 44 spec maps re-embed the same files across ESM/CJS and subpath entries — counting raw occurrences would overstate this by roughly 4x):

DISTINCT src files whose full text is embedded in a shipped map: 1,458
distinct TSDoc /** blocks reachable via maps:                   23,242
distinct // line comments reachable via maps:                   87,281
distinct embedded original-source chars:                    31,473,448

Denominator: 2,024 non-test .ts source files exist in those 57 packages. So 1,458 of 2,024 = 72% of non-test publishable source has its full text in a shipped map. It is not literally every comment: the remainder is @objectstack/cli (124 non-test src files, maps ship but embed nothing), create-objectstack (12, no maps), private packages, and test files — none of which are reached.

For @objectstack/spec specifically, the number that isolates Q1 from Q2: of the 328 distinct sources embedded in its 44 published maps, 206 are .zod.ts files that Q2 already establishes ship as source via files[]. That leaves 122 source files reaching consumers only through the map — text that is in neither .d.ts, nor .js, nor src/**/*.zod.ts.

What I could NOT measure

• 12 publishable packages were not built in this worktree, so they are NOT MEASURED, not "not published": @objectstack/studio, @objectstack/client-react, @objectstack/connector-mcp, @objectstack/connector-openapi, @objectstack/connector-rest, @objectstack/connector-slack, @objectstack/console, @objectstack/embedder-openai, @objectstack/knowledge-memory, @objectstack/knowledge-ragflow, @objectstack/service-cluster-redis, @objectstack/service-knowledge. Each declares the same ["dist","README.md","CHANGELOG.md"], so nothing suggests they differ — but that is an expectation, not a reading.
• The registry check covers 3 packages (spec, types, cli). The other 54 are measured at local-build + npm pack only. The three that were checked matched their local readings, and published spec reports unpackedSize 198,742,329 / fileCount 2,086 against my local dry-run's 200,709,503 / 2,088 — close, not identical, because the local build is a later commit.
• Whether any of this should count as published. Out of scope by dispatch, and it is precisely what The E3 standard needs three written published boundaries — .js.map sourcesContent, @objectstack/spec’s shipped src/**/*.zod.ts, and whether it reaches a defect the round did not cause #15905 asks.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 15905,
  "status": "done",
  "branch": "claude/issue-15905-measure-sourcescontent (worktree only; never pushed — measurement round, no code change)",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Measurement-only round settling Question 1 of #15905: is a published .js.map's sourcesContent a published surface? Both limbs answered YES for 55 of 57 built publishable packages. Maps ship (files[] is a bare 'dist' entry in 68 of 69 publishable packages, no .npmignore anywhere, no stripping in the release pipeline) and sourcesContent is populated in the shipped ones, carrying original source verbatim including comments. Confirmed against the tarballs npm actually serves, not only local dist. The class splits by build tool: tsup/esbuild packages embed source text; the one tsc-built package (@objectstack/cli) ships 238 maps with sourcesContent absent and sources pointing at a src/ that is not in its tarball (dead references); create-objectstack emits no maps at all. Emission is deliberate (explicit sourcemap:true in root + 19 per-package tsup configs, sourceMap:true in cli's tsconfig.build.json) but the embedding is configured NOWHERE — it is the two toolchains' opposite defaults for an option neither config sets. Full report posted as comment 5552851719 with read-back verified byte-for-byte. No disposition and no recommendation on the ruling, per dispatch.",
  "tests": "No code changed; these are measurements at ea03c7c16 in worktree /home/user/objectstack-measure-15905, git diff --stat empty. Build: os-verify-lock.sh -c 'turbo run build --filter=@objectstack/spec --filter=@objectstack/types --filter=@objectstack/verify --filter=@objectstack/cli --filter=create-objectstack --concurrency=2' -> 'os-verify-lock: VERDICT command-exit 0 · held the lock 247s', '57 successful, 57 total'. R1 map survey EXIT_R1FULL=0: 57 built publishable pkgs, 56 emit maps, 338 js-ish maps (327 with real sources, 200 populated), 122 .d.ts.map (0 populated). Positive control EXIT_R1B=0: cli/dist/index.js.map has sources=1 and mappings.len=2282 PRESENT while sourcesContent is ABSENT, beside spec/dist/index.js.map with sourcesContent array len 110 — the zero is a real absence, not a read failure. R2 shipping EXIT_CENSUS=0 (68/69 files[] = dist,README,CHANGELOG), EXIT_NPMIGNORE_LS=2 (no .npmignore), npm pack --dry-run sweep over all 57 all exit 0, EXIT_SWEEPSUM=0: tarball map counts 338 js + 122 dts EXACTLY equal on-disk counts, map bytes 196466298 of 398316339 unpacked = 49.3%. Tie-check EXIT_TIE=0: spec dist/index.js.map tarball size 4938676 == on-disk 4938676. Registry: npm pack @objectstack/types EXIT_REGPACK=0, @objectstack/cli EXIT_REGPACK_CLI=0, @objectstack/spec@17.3.0 EXIT_REGPACK_SPEC=0 -> published spec serves 44 maps, 44 populated; published cli serves 238 maps, 0 populated, no src/ in tarball. R3 content EXIT_R3C=0: 'differs otherwise=0' across 4 maps; spec's only delta is the injected /* @__PURE__ */ token, and stripping exactly that token restores byte-equality with the source file (EXIT_R3B=0). Verbatim @internal 'Test-only' docblock recovered from inside the registry tarball (EXIT_TAR_REG=0). R4 config EXIT_G1=0 (sourcesContent appears nowhere in config, one CHANGELOG prose hit), EXIT_G2=0 (inlineSources only an unrelated local variable in scripts/check-self-test-wired.mjs). Scale, de-duplicated EXIT_SCALE=0: 1458 distinct src files of 2024 non-test .ts (72%) have full text in a shipped map; 23242 distinct TSDoc blocks, 87281 distinct line comments. All exit codes captured before any pipe via 'cmd > file 2>&1; EXIT=$?'.",
  "mcp_calls": "0 — issue body read via the zero-quota public-repo page payload channel; comment posted and read back via repo-scoped REST (probe HTTP 200, POST HTTP 201, read-back HTTP 200). No MCP GitHub calls.",
  "open_questions": [],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[claude]

Question 1 is now a fact, not an inherited claim — and the fact is richer than the question. ⛔ Still no disposition: the ruling's meaning remains the maintainer's.

domain:devx dispatching seat, session_01ARYe3yQTQCUFm5qPYNgKaJ, adopting the measurement round posted above (5552851719). This card filed Question 1 with an explicit ⚠️ NOT re-measured marker on the only evidence it had. That marker is now discharged.

The answer: YES on both limbs, for 55 of 57 built publishable packages

limb	reading
do the maps ship?	yes — files[] is a bare dist entry in 68 of 69 publishable packages, no .npmignore anywhere, no stripping in the release pipeline
is sourcesContent populated in the shipped ones?	yes, carrying original source verbatim including comments

⭐ Confirmed against the tarballs npm actually serves, ⛔ not only a local dist/. @objectstack/spec@17.3.0 from the registry serves 44 maps, 44 populated; tarball map counts (338 js + 122 dts) exactly equal the on-disk counts, and a tie-check has spec's index.js.map at 4,938,676 bytes in the tarball == on disk. A verbatim @internal 'Test-only' docblock was recovered from inside the registry tarball. Maps are 49.3% of unpacked bytes.

That is the limb this card's own suggested command did not reach, and it is the one that decides the question.

⭐ The finding neither the card nor its counter-argument anticipated: nobody chose this

Emission is deliberate — explicit sourcemap: true in the root config and 19 per-package tsup configs, sourceMap: true in the cli's tsconfig.build.json.

The embedding is configured NOWHERE. sourcesContent appears in no config file; inlineSources appears only as an unrelated local variable in an unrelated script. ⇒ whether a package publishes its source text is the two toolchains' opposite defaults for an option neither config sets.

⚠️ And so the class is not uniform, which means 「is sourcesContent published?」 has no single answer today:

• tsup/esbuild packages embed the source text;
• the one tsc-built package, @objectstack/cli, ships 238 maps with sourcesContent absent and sources pointing at a src/ that is not in its tarball — dead references;
• create-objectstack emits no maps at all.

⭐ The counter-argument now has a magnitude, which is what makes this decidable

The strongest argument on record against the expansive reading is that it 「would sweep essentially every comment in the repo into the must-fix-in-round class — a reading that empties the category the ruling created cannot be the ruling's meaning」. That was an argument. It is now a measurement:

1458 distinct source files of 2024 non-test .ts — 72% — have their full text in a shipped map. 23,242 distinct TSDoc blocks. 87,281 distinct line comments.

⇒ the argument is not rhetorical, and it is not refuted either. Whoever rules now knows exactly what each reading costs.

The instrument, because the zero had to be real

@objectstack/cli's dist/index.js.map has sources = 1 and mappings of length 2282 PRESENT while sourcesContent is ABSENT, read beside spec's populated array of 110. ⇒ the absence is a real absence, ⛔ not a read failure. And the content check found spec's only delta from its source file is the injected /* @__PURE__ */ token — stripping exactly that token restores byte-equality.

⛔ What is still open

⛔ This does not answer Question 1's ruling — only its fact. E3 makes 「published」 a measurement against built dist/**/*.d.ts and dist/**/*.{js,mjs,cjs}; a .js.map is in dist/ and is neither of those globs, so the ruling's own instrument returns no while the shipping reality returns yes. That gap is the question, and it is the maintainer's.

⭐ A third reading the measurement makes available, offered as a fact about the option space and ⛔ not a recommendation: because the embedding is nobody's decision, 「turn it off」 is on the table alongside 「it counts」 and 「it does not」 — and the cli already demonstrates the shape of a package that publishes maps without source text.

Questions 2 (@objectstack/spec ships src/**/*.zod.ts, measured) and 3 (does 「已发布必修」 reach a defect a round noticed but did not cause) remain open exactly as filed.

---

Generated by Claude Code