Filed by the #15976 implementer as an out-of-scope finding, crossed while running that card's gate union. ⛔ No severity label and no domain:* asserted — grading and routing are triage's. Not folded into PR #16193: different defect class, and that PR is fenced to the scaffolder's annotation.
Measured
Two independent facts, each measured on origin/main at be754938a33 in a normal worktree.
1. The walk includes git-ignored directories. check:keyed-text-bounds describes its population as "walk is repo-wide". It reached packages/cli/tmp/**, which is git-ignored by the root .gitignore rule tmp/:
packages/cli/tmp/full-plugin-oPyYc7/src/objects/my_app_item.object.ts:1
no object declaration recognised in a `.object.ts` file.
packages/cli/tmp/repro-init-app-raJSDn/src/objects/my_app_item.object.ts:1
no object declaration recognised in a `.object.ts` file.
packages/cli/tmp/repro-init-plugin-o8Ribf/src/objects/my_app_item.object.ts:1
no object declaration recognised in a `.object.ts` file.
check:keyed-text-bounds exit 2
rm -rf packages/cli/tmp and re-running is the whole fix — the same command then exits 0 and reports 112 *.object.ts files … 148 keyed text-family columns judged, 148 bounded.
2. The scan does not recognise the declaration shape os init emits. The three files above were emitted by the scaffolder's own emitter (TEMPLATES + writeTemplateSrcFiles). The shape is a plain annotated object literal:
import * as Data from '@objectstack/spec/data';
const myAppItem: Data.ServiceObject = {
name: 'my_app_item',
fields: { … },
sharingModel: 'private',
};
export default myAppItem;
The 112 *.object.ts files the gate does parse are all the ObjectSchema.create({ … }) factory shape (examples/app-showcase/src/data/objects/*.object.ts). ⚠️ Measured with the repaired annotation, so this is not an effect of #15976's Data.Object defect — the literal shape is unrecognised either way.
Why the two together matter
packages/cli/test/init-scaffold-authoring-rules.test.ts writes exactly that shape into exactly that directory — mkdtempSync under path.resolve(HERE, '../tmp') — and removes it in afterAll. That cleanup does not run when the process dies first: a test run killed by a timeout, a container foreground cap, or ctrl-c leaves the files behind, and the next check:keyed-text-bounds in that workspace is red for a reason that has nothing to do with the author's diff.
The gate's own refusal text is right that an unclassifiable shape on a keyed column must be a refusal rather than a pass — that is the design and it is not in question here. What is in question is the population the refusal ranges over.
Not claimed
⛔ Not swept: whether CI can reach this state at all (each job takes a fresh checkout, so the leftover probably cannot survive there — this is measured as a local failure mode only). ⛔ No repair proposed, and the choice is a real one with at least three shapes, none of them obviously right:
- the walk honours
.gitignore (or skips tmp/ the way it already skips node_modules);
- the scan learns the plain-literal declaration shape, with a
--self-test case, so a scaffolded object file is judged rather than refused;
- the scaffold test's temp root moves under
packages/cli/node_modules/, the placement generate-scaffold-validates.test.ts already measured and documented for the same reason.
The second is not merely a cleanup: it would mean the repo's own gate and the repo's own scaffolder currently disagree about how an object file may be written, which is a question worth answering deliberately rather than as a side effect.
Refs: #15976 / PR #16193 (the run that crossed this).
Filed by the #15976 implementer as an out-of-scope finding, crossed while running that card's gate union. ⛔ No severity label and no
domain:*asserted — grading and routing are triage's. Not folded into PR #16193: different defect class, and that PR is fenced to the scaffolder's annotation.Measured
Two independent facts, each measured on
origin/mainatbe754938a33in a normal worktree.1. The walk includes git-ignored directories.
check:keyed-text-boundsdescribes its population as "walk is repo-wide". It reachedpackages/cli/tmp/**, which is git-ignored by the root.gitignoreruletmp/:rm -rf packages/cli/tmpand re-running is the whole fix — the same command then exits 0 and reports112 *.object.ts files … 148 keyed text-family columns judged, 148 bounded.2. The scan does not recognise the declaration shape
os initemits. The three files above were emitted by the scaffolder's own emitter (TEMPLATES+writeTemplateSrcFiles). The shape is a plain annotated object literal:The 112⚠️ Measured with the repaired annotation, so this is not an effect of #15976's
*.object.tsfiles the gate does parse are all theObjectSchema.create({ … })factory shape (examples/app-showcase/src/data/objects/*.object.ts).Data.Objectdefect — the literal shape is unrecognised either way.Why the two together matter
packages/cli/test/init-scaffold-authoring-rules.test.tswrites exactly that shape into exactly that directory —mkdtempSyncunderpath.resolve(HERE, '../tmp')— and removes it inafterAll. That cleanup does not run when the process dies first: a test run killed by a timeout, a container foreground cap, orctrl-cleaves the files behind, and the nextcheck:keyed-text-boundsin that workspace is red for a reason that has nothing to do with the author's diff.The gate's own refusal text is right that an unclassifiable shape on a keyed column must be a refusal rather than a pass — that is the design and it is not in question here. What is in question is the population the refusal ranges over.
Not claimed
⛔ Not swept: whether CI can reach this state at all (each job takes a fresh checkout, so the leftover probably cannot survive there — this is measured as a local failure mode only). ⛔ No repair proposed, and the choice is a real one with at least three shapes, none of them obviously right:
.gitignore(or skipstmp/the way it already skipsnode_modules);--self-testcase, so a scaffolded object file is judged rather than refused;packages/cli/node_modules/, the placementgenerate-scaffold-validates.test.tsalready measured and documented for the same reason.The second is not merely a cleanup: it would mean the repo's own gate and the repo's own scaffolder currently disagree about how an object file may be written, which is a question worth answering deliberately rather than as a side effect.
Refs: #15976 / PR #16193 (the run that crossed this).