@mulmoclaude/core 4.2.0 → 4.3.0

package/dist/{server-DZkN0GGh.cjs → server-CF1qllGV.cjs}

@@ -1568,6 +1568,22 @@ var MAX_SCHEMA_ISSUES = 20;
 *  write that reported success would leave a half-filled collection nobody
 *  knows is half-filled. */
 var MAX_PUT_ITEMS = 1e3;
+/** Cap the strict-tier findings one putItems call reports back. The rows were
+*  WRITTEN, so this is a report and not a refusal — and a generated batch is
+*  wrong the same way in every row, which means ten samples plus the total say
+*  everything a thousand would. */
+var MAX_PUT_LINT = 10;
+/** What the `lint` block SAYS, once per call. A bare list of findings on rows the
+*  call also reports as `written` reads as noise; the reason to act is that the
+*  next reader of these rows is stricter than the write was.
+*
+*  Like everything else the tool says about validation, this describes the tool
+*  with its gate ON. Under `ablateValidation` nothing is checked — `rejected`
+*  stays empty too — and the caveat is deliberately NOT written into the
+*  agent-facing text: ablation exists to measure what a model does without the
+*  guardrails, and a model told "unless ablation is on" is no longer without
+*  them (CodeRabbit on #2925). */
+var PUT_LINT_NOTE = "These rows WERE written. The write gate refuses what would make a record unopenable — a missing required field, a value outside an enum, a mismatched primaryKey, a computed key, a colliding id under `create` — but it does not check the SHAPE of a value, so a wrong-shaped one is reported here rather than rejected. `getItems` surfaces the same finding as a `warning` (on a full listing, or when a requested id is missing), and publishing a shared app REFUSES the row outright. Fix the generator and rewrite them before writing the rest of the set.";
 /** Refuse an `itemsFile` larger than this, from `stat` and before any read.
 *  The row cap alone cannot bound the work: the file has to be read and parsed
 *  WHOLE before there are rows to count, so a huge blob is paid for in full
@@ -1736,6 +1752,26 @@ async function mergeWithExisting(collection, store, record, itemId) {
 		...record
 	};
 }
+/** The strict-tier finding on a row the write gate LET THROUGH, or nothing.
+*
+*  The gate stays exactly where it was — `lint-not-lock` is why the strict tier
+*  exists (see `../core/recordZ`), and turning these into rejections would make
+*  a collection whose legacy rows predate the typed rules unwritable. What was
+*  missing is that the row's author never HEARD about it: `getItems` reports the
+*  same finding and publishing a shared app refuses exactly these rows, so the
+*  one surface that stayed silent was the one that could still fix the generator
+*  before it wrote the other 719 rows (mulmoterminal#1763).
+*
+*  Run against the record as WRITTEN (`toWrite`, post-merge, post-defaults) —
+*  what a later read will lint is what landed, not what the caller sent. */
+function lintOf(record, itemId, schema, deps) {
+	if (deps.ablateValidation) return {};
+	const problem = validateRecordObject(record, itemId, schema, "strict");
+	return problem ? { lint: {
+		id: require_promptSafety.defangForPrompt(itemId),
+		problem: require_promptSafety.defangForPrompt(problem)
+	} } : {};
+}
 async function putOneItem(collection, store, write, record, mode, deps) {
 	const { schema } = collection;
 	const created = mode === "create" ? {
@@ -1761,7 +1797,10 @@ async function putOneItem(collection, store, write, record, mode, deps) {
 		if (invalid) return reject(itemId, invalid);
 	}
 	const result = await write(itemId, toWrite, { refuseOverwrite: mode === "create" });
-	if (result.kind === "ok") return { written: result.itemId };
+	if (result.kind === "ok") return {
+		written: result.itemId,
+		...lintOf(toWrite, result.itemId, schema, deps)
+	};
 	if (result.kind === "invalid-id") return reject(itemId, `'${itemId}' is not a valid record id (letters/digits at the ends; -, _, or . inside; no '..' or path characters)`);
 	if (result.kind === "conflict") return reject(itemId, `'${itemId}' already exists — mode "create" refuses overwrite; use "upsert" to update it`);
 	return reject(itemId, "write refused: the collection's data dir escapes the workspace");
@@ -1934,23 +1973,51 @@ async function resolvePutRows(args, deps) {
 	if (rows.length > 1e3) return `manageCollection: refused — ${rows.length} rows is over the putItems limit of ${MAX_PUT_ITEMS}. Nothing was written; split them across several calls.`;
 	return rows;
 }
-async function handlePutItems(collection, args, deps) {
-	const store = require_discovery.storeFor(collection, { workspaceRoot: deps.workspaceRoot });
-	const { write } = store;
-	if (!write) return `manageCollection: ${require_discovery.readOnlyRefusal(collection.slug)} (its records are the rows of '${collection.schema.dataSource?.path}'; edit that file to change the data).`;
-	const rows = await resolvePutRows(args, deps);
-	if (typeof rows === "string") return rows;
+/** The `lint` block of a putItems result, or nothing when every written row is
+*  clean — absent rather than empty, so a clean call reads exactly as it always
+*  did and the key's presence is itself the signal.
+*
+*  `total` counts every flagged row and `rows` shows the first
+*  `MAX_PUT_LINT` of them, so a capped report can never be read as a total. */
+function lintReport(lint) {
+	if (lint.length === 0) return {};
+	return { lint: {
+		total: lint.length,
+		note: PUT_LINT_NOTE,
+		rows: lint.slice(0, 10)
+	} };
+}
+/** Write the batch row by row, sorting each outcome into its own list. One row
+*  at a time on purpose: a rejection is per row, so a bad row must not take the
+*  batch with it. */
+async function putEachRow(collection, store, write, rows, mode, deps) {
 	const written = [];
 	const rejected = [];
+	const lint = [];
 	for (const record of rows) {
-		const outcome = await putOneItem(collection, store, write, record, args.mode, deps);
+		const outcome = await putOneItem(collection, store, write, record, mode, deps);
 		if (outcome.written) written.push(outcome.written);
 		if (outcome.rejected) rejected.push(outcome.rejected);
+		if (outcome.lint) lint.push(outcome.lint);
 	}
+	return {
+		written,
+		rejected,
+		lint
+	};
+}
+async function handlePutItems(collection, args, deps) {
+	const store = require_discovery.storeFor(collection, { workspaceRoot: deps.workspaceRoot });
+	const { write } = store;
+	if (!write) return `manageCollection: ${require_discovery.readOnlyRefusal(collection.slug)} (its records are the rows of '${collection.schema.dataSource?.path}'; edit that file to change the data).`;
+	const rows = await resolvePutRows(args, deps);
+	if (typeof rows === "string") return rows;
+	const { written, rejected, lint } = await putEachRow(collection, store, write, rows, args.mode, deps);
 	return JSON.stringify({
 		collection: collection.slug,
 		written,
-		rejected
+		rejected,
+		...lintReport(lint)
 	});
 }
 /** Delete records by id, through the store — so it works on any writable
@@ -2160,7 +2227,7 @@ async function handlePutSchema(slug, schemaArg, deps) {
 		written: true
 	});
 }
-var MANAGE_COLLECTION_PROMPT = "Use `manageCollection` instead of raw Read/Write/Edit when working with a collection's records OR its schema (raw file I/O stays available as the escape hatch). Before authoring or changing a collection's `schema.json`, call `schemaDocs` to load the field/DSL reference — the default reply is the core authoring guide plus a table of contents; fetch advanced sections (actions, bells, calendar/kanban views, dataSource, storage) by passing their heading as `topic` rather than dumping `topic: \"all\"`. Then read with `getSchema` and write with `putSchema` — `putSchema` validates the whole schema before writing and returns actionable errors instead of silently failing discovery's validation. `getItems` is the only way to see computed values — `derived` fields (e.g. a portfolio's value), `toggle` projections, and `embed` records are host-computed and never present in the stored JSON files. On large collections pass `ids` and/or `fields` to keep the result small. For a question that spans collections (\"which clients have unpaid invoices?\"), start with `getOntology`: it lists every collection with its primaryKey, record count, and outbound `ref`/`embed` relations, so you know which collections to join before reading any records. `putItems` validates every row against the schema before writing (required fields, enum values, primaryKey = record id) and returns `{ written, rejected }`; fix each rejected row using its `problem` text and retry just those rows. Never include computed fields in a row you write. When the rows come from a script rather than from you (a generated schedule, an imported set, anything past a few dozen records), write them to a JSON file UNDER THE WORKSPACE and pass its absolute path as `itemsFile` instead of `items` — the host reads the file, so the rows never pass through your context. Do NOT hand-transcribe a generated file into `items`, and never drive the collection by spawning the MCP bridge yourself. To update a few fields of an existing record, use `mode: \"merge\"` with a partial row ({ id, <changed fields> }) — the default upsert replaces the WHOLE record, so a partial upsert would silently erase every optional field it omits. `deleteItems` removes records by id and returns `{ deleted, rejected }`; an id that doesn't exist comes back rejected rather than counted as deleted, so check `rejected` before reporting a deletion as done. Answer aggregation questions (counts, sums, averages, group-bys) with `queryItems` on ANY collection — on a dataSource (CSV) collection it scans the whole file (getItems is row-capped, so aggregates computed from its output can be silently wrong on large files); on a file-backed collection it aggregates the enriched records, so computed fields (derived/rollup/toggle) are queryable columns.";
+var MANAGE_COLLECTION_PROMPT = "Use `manageCollection` instead of raw Read/Write/Edit when working with a collection's records OR its schema (raw file I/O stays available as the escape hatch). Before authoring or changing a collection's `schema.json`, call `schemaDocs` to load the field/DSL reference — the default reply is the core authoring guide plus a table of contents; fetch advanced sections (actions, bells, calendar/kanban views, dataSource, storage) by passing their heading as `topic` rather than dumping `topic: \"all\"`. Then read with `getSchema` and write with `putSchema` — `putSchema` validates the whole schema before writing and returns actionable errors instead of silently failing discovery's validation. `getItems` is the only way to see computed values — `derived` fields (e.g. a portfolio's value), `toggle` projections, and `embed` records are host-computed and never present in the stored JSON files. On large collections pass `ids` and/or `fields` to keep the result small. For a question that spans collections (\"which clients have unpaid invoices?\"), start with `getOntology`: it lists every collection with its primaryKey, record count, and outbound `ref`/`embed` relations, so you know which collections to join before reading any records. `putItems` GATES every row on what would make the record unopenable — required fields, enum values, primaryKey = record id — and returns `{ written, rejected }`; fix each rejected row using its `problem` text and retry just those rows. Never include computed fields in a row you write. That gate does NOT check the SHAPE of a value: a `datetime` written as an instant (`2026-08-17T15:00:00.000Z`, what `toISOString()` produces) rather than as a wall clock, a `number` holding something that is not a number at all, a `date` that is not a real day are all WRITTEN, and come back in a `lint` block beside `written`. Read it — a full `getItems` listing warns about the same rows and publishing a shared app REFUSES them, so a silent `lint` is the only proof the values are right. Before generating a large set, read the exact stored form of each type in the `Field types` section of `schemaDocs` (`topic: \"Field types\"` fetches just that one), then write ONE batch and check that `lint` is absent. `datetime` in particular is a local wall clock (`YYYY-MM-DDTHH:MM`, no timezone suffix), so `new Date(...).toISOString()` is wrong twice over — the suffix, and the hours the conversion moved. The one `Z`-suffixed datetime the strict tier accepts is a shared app's server-stamped instant, written by the SERVER with nine fractional digits; you never produce that value. When the rows come from a script rather than from you (a generated schedule, an imported set, anything past a few dozen records), write them to a JSON file UNDER THE WORKSPACE and pass its absolute path as `itemsFile` instead of `items` — the host reads the file, so the rows never pass through your context. Do NOT hand-transcribe a generated file into `items`, and never drive the collection by spawning the MCP bridge yourself. To update a few fields of an existing record, use `mode: \"merge\"` with a partial row ({ id, <changed fields> }) — the default upsert replaces the WHOLE record, so a partial upsert would silently erase every optional field it omits. `deleteItems` removes records by id and returns `{ deleted, rejected }`; an id that doesn't exist comes back rejected rather than counted as deleted, so check `rejected` before reporting a deletion as done. Answer aggregation questions (counts, sums, averages, group-bys) with `queryItems` on ANY collection — on a dataSource (CSV) collection it scans the whole file (getItems is row-capped, so aggregates computed from its output can be silently wrong on large files); on a file-backed collection it aggregates the enriched records, so computed fields (derived/rollup/toggle) are queryable columns.";
 /** Validate getItems' optional `ids`/`fields` args, then delegate. */
 async function dispatchGetItems(collection, args, deps) {
 	const ids = optionalStringArray(args.ids, "ids");
@@ -2216,7 +2283,7 @@ async function dispatchManageCollection(deps, args) {
 }
 var MANAGE_COLLECTION_DEFINITION = {
 	name: "manageCollection",
-	description: "Read and write a schema-driven collection through the host — both its records and its structure. getItems returns records WITH computed values (derived formulas, toggles, embeds) the stored JSON files don't contain; putItems validates each row against the schema before writing; deleteItems removes records by id. getOntology maps the whole workspace: every collection with its record count and outbound ref/embed relations — call it first for cross-collection questions. schemaDocs returns the collection-authoring reference — the core guide plus a table of contents by default; pass `topic` for a specific section. getSchema/putSchema read and validate-then-write the collection's schema.json. Prefer it over raw file I/O on collections.",
+	description: "Read and write a schema-driven collection through the host — both its records and its structure. getItems returns records WITH computed values (derived formulas, toggles, embeds) the stored JSON files don't contain; putItems gates each row on required/enum/primaryKey before writing and lints the value shapes it does not gate; deleteItems removes records by id. getOntology maps the whole workspace: every collection with its record count and outbound ref/embed relations — call it first for cross-collection questions. schemaDocs returns the collection-authoring reference — the core guide plus a table of contents by default; pass `topic` for a specific section. getSchema/putSchema read and validate-then-write the collection's schema.json. Prefer it over raw file I/O on collections.",
 	inputSchema: {
 		type: "object",
 		properties: {
@@ -2303,6 +2370,12 @@ Object.defineProperty(exports, "MAX_PUT_ITEMS", {
 		return MAX_PUT_ITEMS;
 	}
 });
+Object.defineProperty(exports, "MAX_PUT_LINT", {
+	enumerable: true,
+	get: function() {
+		return MAX_PUT_LINT;
+	}
+});
 Object.defineProperty(exports, "MAX_RECORD_ISSUES", {
 	enumerable: true,
 	get: function() {
@@ -2520,4 +2593,4 @@ Object.defineProperty(exports, "validateRecordObject", {
 	}
 });
 
-//# sourceMappingURL=server-DZkN0GGh.cjs.map
+//# sourceMappingURL=server-CF1qllGV.cjs.map