@anchrd/intel-contract 0.11.0 → 0.12.0

package/dist/contract/contract.d.ts

@@ -497,7 +497,22 @@ export type BoardAssignee = z.infer<typeof BoardAssignee>;
  * mints a key between theirs, so moving one task writes one task and renumbers nothing — the whole
  * reason a board is not addressed by position the way a table's rows are (`TableRowPosition`).
  * A hand-written key could collide, and two tasks sharing a key have no defined order at all.
+ *
+ * ⚠️ This CHARACTER CLASS is the truth about a stored key, not `fractional-indexing`, and the two
+ * are deliberately not the same set (anchrd/intel#359). A board that arrived through a bundle may
+ * spell `"0"`, `"a00"`, `"zzz"` or `"A"` — all of them legal here, none of them readable by that
+ * library. Narrowing the regex to what it reads would be a rule on the STORED document, so a board
+ * carrying one would stop parsing in all four places a board body is read (the board read, the
+ * indexer, the link reader, the bundle import) — unreadable, unsearchable and unmovable at once,
+ * over a value its owner never wrote. That is the trap #311, #318 and #321 each walked into from a
+ * different side.
+ *
+ * ⚠️ What every consumer may therefore rely on is exactly what stands here: keys are non-empty
+ * strings over `[0-9A-Za-z]` and are ORDERED BY STRING COMPARISON. Nothing may assume more — and
+ * `packages/api`'s `orderBetween` is the one place that asks `fractional-indexing` for a key and
+ * carries on without it when it refuses a bound.
  */
+export declare const MaxBoardTaskOrderLength = 64;
 export declare const BoardTaskOrder: z.ZodString;
 export declare const BoardTaskId: z.ZodString;
 export declare const BoardTaskLabel: z.ZodString;
@@ -739,6 +754,24 @@ export declare const DeleteBoardTaskInput: z.ZodObject<{
     idempotencyKey: z.ZodString;
 }, z.core.$strict>;
 export type DeleteBoardTaskInput = z.infer<typeof DeleteBoardTaskInput>;
+/**
+ * The way out of a board whose `tasks[]` names one id twice (anchrd/intel#341).
+ *
+ * ⚠️ It names no task, and that is not an oversight. Such a board holds a pair the caller cannot
+ * tell apart — every other operation here addresses a task BY id (#285), so the one thing nobody
+ * can say is "the second of the two". The board is what is named, and the server does the one thing
+ * that removes the ambiguity: the first entry under an id keeps it, every later one gets a freshly
+ * minted id and keeps everything else it carries.
+ *
+ * ⚠️ It exists because the pair is deliberately NOT folded away on read (`upgradeStoredBoard`,
+ * `repeatedBoardId`): two tasks under one id are two whole tasks, and a fold on the read is written
+ * back by the next save of any kind. So somebody has to ask for the repair, and this is the asking.
+ */
+export declare const RepairBoardTaskIdsInput: z.ZodObject<{
+    nodeId: z.ZodString;
+    idempotencyKey: z.ZodString;
+}, z.core.$strict>;
+export type RepairBoardTaskIdsInput = z.infer<typeof RepairBoardTaskIdsInput>;
 export declare const BoardTaskResult: z.ZodObject<{
     node: z.ZodObject<{
         id: z.ZodString;
@@ -877,6 +910,78 @@ export declare const ConfigureBoardResult: z.ZodObject<{
     }, z.core.$strict>>;
 }, z.core.$strict>;
 export type ConfigureBoardResult = z.infer<typeof ConfigureBoardResult>;
+/**
+ * What the repair did, task by task (anchrd/intel#341).
+ *
+ * ⚠️ `previousId` is the id the entry shared, and it still names a task on this board — the FIRST
+ * entry under it, the one that kept it. That is what makes the repair readable: nothing that
+ * pointed at that id moved, so a caller can see which of the two the board's `parentId` and
+ * `dependsOn` edges have been meaning all along, and move them with `board_task_move` and
+ * `board_task_update` if they meant the other one.
+ *
+ * ⚠️ At least one entry, because a board with nothing to repair is refused rather than answered
+ * with an empty list and a new version that changed nothing.
+ */
+export declare const RepairBoardTaskIdsResult: z.ZodObject<{
+    node: z.ZodObject<{
+        id: z.ZodString;
+        parentId: z.ZodNullable<z.ZodString>;
+        kind: z.ZodEnum<{
+            folder: "folder";
+            document: "document";
+            attachment: "attachment";
+            table: "table";
+            agent: "agent";
+            board: "board";
+        }>;
+        title: z.ZodString;
+        description: z.ZodNullable<z.ZodString>;
+        ownerId: z.ZodString;
+        currentVersionId: z.ZodNullable<z.ZodString>;
+        createdAt: z.ZodISODateTime;
+        updatedAt: z.ZodISODateTime;
+        archivedAt: z.ZodNullable<z.ZodISODateTime>;
+    }, z.core.$strict>;
+    version: z.ZodObject<{
+        id: z.ZodString;
+        nodeId: z.ZodString;
+        sequence: z.ZodNumber;
+        contentKey: z.ZodString;
+        mediaType: z.ZodString;
+        contentHash: z.ZodString;
+        size: z.ZodNumber;
+        segment: z.ZodNullable<z.ZodEnum<{
+            append: "append";
+            snapshot: "snapshot";
+        }>>;
+        createdBy: z.ZodString;
+        createdAt: z.ZodISODateTime;
+    }, z.core.$strict>;
+    renumbered: z.ZodArray<z.ZodObject<{
+        previousId: z.ZodString;
+        task: z.ZodObject<{
+            id: z.ZodString;
+            title: z.ZodString;
+            status: z.ZodString;
+            assignee: z.ZodNullable<z.ZodDiscriminatedUnion<[z.ZodObject<{
+                type: z.ZodLiteral<"user">;
+                id: z.ZodString;
+            }, z.core.$strict>, z.ZodObject<{
+                type: z.ZodLiteral<"agent">;
+                nodeId: z.ZodString;
+            }, z.core.$strict>], "type">>;
+            labels: z.ZodArray<z.ZodString>;
+            startDate: z.ZodNullable<z.ZodISODate>;
+            dueDate: z.ZodNullable<z.ZodISODate>;
+            parentId: z.ZodNullable<z.ZodString>;
+            dependsOn: z.ZodArray<z.ZodString>;
+            order: z.ZodString;
+            description: z.ZodString;
+            references: z.ZodArray<z.ZodString>;
+        }, z.core.$strict>;
+    }, z.core.$strict>>;
+}, z.core.$strict>;
+export type RepairBoardTaskIdsResult = z.infer<typeof RepairBoardTaskIdsResult>;
 export declare const AgentMediaType = "application/vnd.anchrd.agent+json";
 export declare const AgentReferenceRole: z.ZodEnum<{
     "system-message": "system-message";

package/dist/contract/contract.js

@@ -336,8 +336,28 @@ export const BoardAssignee = z.discriminatedUnion("type", [
  * mints a key between theirs, so moving one task writes one task and renumbers nothing — the whole
  * reason a board is not addressed by position the way a table's rows are (`TableRowPosition`).
  * A hand-written key could collide, and two tasks sharing a key have no defined order at all.
+ *
+ * ⚠️ This CHARACTER CLASS is the truth about a stored key, not `fractional-indexing`, and the two
+ * are deliberately not the same set (anchrd/intel#359). A board that arrived through a bundle may
+ * spell `"0"`, `"a00"`, `"zzz"` or `"A"` — all of them legal here, none of them readable by that
+ * library. Narrowing the regex to what it reads would be a rule on the STORED document, so a board
+ * carrying one would stop parsing in all four places a board body is read (the board read, the
+ * indexer, the link reader, the bundle import) — unreadable, unsearchable and unmovable at once,
+ * over a value its owner never wrote. That is the trap #311, #318 and #321 each walked into from a
+ * different side.
+ *
+ * ⚠️ What every consumer may therefore rely on is exactly what stands here: keys are non-empty
+ * strings over `[0-9A-Za-z]` and are ORDERED BY STRING COMPARISON. Nothing may assume more — and
+ * `packages/api`'s `orderBetween` is the one place that asks `fractional-indexing` for a key and
+ * carries on without it when it refuses a bound.
  */
-export const BoardTaskOrder = z.string().regex(/^[0-9A-Za-z]{1,64}$/);
+// ⚠️ Named because a consumer has to be able to stay inside it. The repair of a repeated task id
+// (anchrd/intel#341) mints a key beside an existing one, and a key one character too long would be
+// written and then refused by the very next read — the whole board lost over a repair.
+export const MaxBoardTaskOrderLength = 64;
+export const BoardTaskOrder = z
+    .string()
+    .regex(new RegExp(`^[0-9A-Za-z]{1,${MaxBoardTaskOrderLength}}$`));
 export const BoardTaskId = IntelId;
 export const BoardTaskLabel = z.string().trim().min(1).max(60);
 // A day, not an instant. A task is due on a date; giving it a time zone would make the same task
@@ -549,6 +569,23 @@ export const DeleteBoardTaskInput = z.strictObject({
     taskId: BoardTaskId,
     idempotencyKey: z.string().min(8).max(200),
 });
+/**
+ * The way out of a board whose `tasks[]` names one id twice (anchrd/intel#341).
+ *
+ * ⚠️ It names no task, and that is not an oversight. Such a board holds a pair the caller cannot
+ * tell apart — every other operation here addresses a task BY id (#285), so the one thing nobody
+ * can say is "the second of the two". The board is what is named, and the server does the one thing
+ * that removes the ambiguity: the first entry under an id keeps it, every later one gets a freshly
+ * minted id and keeps everything else it carries.
+ *
+ * ⚠️ It exists because the pair is deliberately NOT folded away on read (`upgradeStoredBoard`,
+ * `repeatedBoardId`): two tasks under one id are two whole tasks, and a fold on the read is written
+ * back by the next save of any kind. So somebody has to ask for the repair, and this is the asking.
+ */
+export const RepairBoardTaskIdsInput = z.strictObject({
+    nodeId: IntelId,
+    idempotencyKey: z.string().min(8).max(200),
+});
 // The one task that was written, not the whole board: a board can hold thousands of tasks, and
 // answering a one-card edit with all of them would make every write pay for the read.
 export const BoardTaskResult = z.strictObject({
@@ -568,6 +605,26 @@ export const ConfigureBoardResult = z.strictObject({
     version: NodeVersion,
     statuses: z.array(BoardStatus),
 });
+/**
+ * What the repair did, task by task (anchrd/intel#341).
+ *
+ * ⚠️ `previousId` is the id the entry shared, and it still names a task on this board — the FIRST
+ * entry under it, the one that kept it. That is what makes the repair readable: nothing that
+ * pointed at that id moved, so a caller can see which of the two the board's `parentId` and
+ * `dependsOn` edges have been meaning all along, and move them with `board_task_move` and
+ * `board_task_update` if they meant the other one.
+ *
+ * ⚠️ At least one entry, because a board with nothing to repair is refused rather than answered
+ * with an empty list and a new version that changed nothing.
+ */
+export const RepairBoardTaskIdsResult = z.strictObject({
+    node: Node,
+    version: NodeVersion,
+    renumbered: z
+        .array(z.strictObject({ previousId: BoardTaskId, task: BoardTask }))
+        .min(1)
+        .max(5_000),
+});
 // ── The agent definition (#139, ADR-0005 §4) ─────────────────────────────────────────────────────
 //
 // An agent's body is a definition, stored as an immutable version in R2 exactly like a document's.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anchrd/intel-contract",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "type": "module",
   "license": "UNLICENSED",
   "repository": {