@bli-cockpit/telemetry-core 0.1.29 → 0.1.30

package/dist/ingest-dto.d.ts

@@ -401,6 +401,8 @@ export declare const TelemetryIngestEnvelopeSchema: z.ZodObject<{
         started_at: z.ZodString;
         updated_at: z.ZodOptional<z.ZodString>;
         active_ticket_id: z.ZodOptional<z.ZodString>;
+        tower_issue_id: z.ZodOptional<z.ZodString>;
+        linear_ticket_id: z.ZodOptional<z.ZodString>;
         ticket_binding_candidates: z.ZodDefault<z.ZodArray<z.ZodObject<{
             ticket_id: z.ZodString;
             binding_source: z.ZodEnum<{

package/dist/ticket-id.d.ts

@@ -1 +1,44 @@
+/**
+ * WHICH TRACKER MINTED THIS ID (BLI-3779).
+ *
+ * Tower runs its own issue tracker beside Linear during the dual-run, and both
+ * spell an identifier the same way: a team key, a hyphen, a number. Two facts
+ * tell them apart, and neither is a guess:
+ *
+ *  - **The number.** Tower's tracker mints from `BLI-10001` up;
+ *    Linear's BLI team is in the 3,000s. An id at or above
+ *    `TOWER_NATIVE_ISSUE_NUMBER_FLOOR` is one only Tower could have issued.
+ *    The dashboard's `lib/jarvis/chat-v2/issue-word-boundary.ts` (BLI-3783)
+ *    re-exports this constant rather than keeping a second copy of it.
+ *  - **The title.** A Tower-native row that mirrors a Linear ticket ends its
+ *    title with `[BLI-3779]` — Edward's dogfooding convention, 2026-09-05 —
+ *    so the Linear id a Tower row stands for is READ, never inferred.
+ *
+ * Exact after upper-casing, never fuzzy: the `person-identity.ts` discipline,
+ * for the same reason. A wrong match binds a session's work to somebody
+ * else's ticket.
+ */
+/**
+ * The first identifier Tower's own tracker mints. Linear's BLI team is in the
+ * 3,000s as of 2026-09-05 and would need six thousand more tickets to reach
+ * it; if it ever does, this constant moves and `work_issues.source` becomes
+ * the only honest discriminator.
+ */
+export declare const TOWER_NATIVE_ISSUE_NUMBER_FLOOR = 10000;
 export declare function parseTicketIdFromText(value: string): string | null;
+/** Is this the shape either tracker uses for an identifier? */
+export declare function looksLikeIssueIdentifier(value: string): boolean;
+/** The one spelling of an identifier: trimmed and upper-cased, or null. */
+export declare function normalizeIssueIdentifier(value: string): string | null;
+/**
+ * Is this an id only TOWER's tracker could have minted? A fact about the
+ * number, not a claim about any row: `BLI-10042` cannot be in Linear whether
+ * or not it is in Tower.
+ */
+export declare function isTowerNativeIssueId(value: string): boolean;
+/**
+ * The Linear id a Tower-native title mirrors: the LAST `[BLI-3779]` in the
+ * title, because a title may quote another ticket in its prose and the
+ * convention puts the mirrored id at the end.
+ */
+export declare function mirroredTicketIdInTitle(title: string): string | null;

package/dist/ticket-id.js

@@ -1,4 +1,61 @@
+/**
+ * WHICH TRACKER MINTED THIS ID (BLI-3779).
+ *
+ * Tower runs its own issue tracker beside Linear during the dual-run, and both
+ * spell an identifier the same way: a team key, a hyphen, a number. Two facts
+ * tell them apart, and neither is a guess:
+ *
+ *  - **The number.** Tower's tracker mints from `BLI-10001` up;
+ *    Linear's BLI team is in the 3,000s. An id at or above
+ *    `TOWER_NATIVE_ISSUE_NUMBER_FLOOR` is one only Tower could have issued.
+ *    The dashboard's `lib/jarvis/chat-v2/issue-word-boundary.ts` (BLI-3783)
+ *    re-exports this constant rather than keeping a second copy of it.
+ *  - **The title.** A Tower-native row that mirrors a Linear ticket ends its
+ *    title with `[BLI-3779]` — Edward's dogfooding convention, 2026-09-05 —
+ *    so the Linear id a Tower row stands for is READ, never inferred.
+ *
+ * Exact after upper-casing, never fuzzy: the `person-identity.ts` discipline,
+ * for the same reason. A wrong match binds a session's work to somebody
+ * else's ticket.
+ */
+/** `BLI-3654`, `TRI-12` — a team key, a hyphen, a number, and nothing else. */
+const ISSUE_IDENTIFIER = /^[A-Z][A-Z0-9]{1,12}-\d+$/;
+/**
+ * The first identifier Tower's own tracker mints. Linear's BLI team is in the
+ * 3,000s as of 2026-09-05 and would need six thousand more tickets to reach
+ * it; if it ever does, this constant moves and `work_issues.source` becomes
+ * the only honest discriminator.
+ */
+export const TOWER_NATIVE_ISSUE_NUMBER_FLOOR = 10_000;
 export function parseTicketIdFromText(value) {
     const match = value.match(/\b[A-Z][A-Z0-9]{1,12}-\d+\b/);
     return match?.[0] ?? null;
 }
+/** Is this the shape either tracker uses for an identifier? */
+export function looksLikeIssueIdentifier(value) {
+    return ISSUE_IDENTIFIER.test(value.trim().toUpperCase());
+}
+/** The one spelling of an identifier: trimmed and upper-cased, or null. */
+export function normalizeIssueIdentifier(value) {
+    const normalized = value.trim().toUpperCase();
+    return ISSUE_IDENTIFIER.test(normalized) ? normalized : null;
+}
+/**
+ * Is this an id only TOWER's tracker could have minted? A fact about the
+ * number, not a claim about any row: `BLI-10042` cannot be in Linear whether
+ * or not it is in Tower.
+ */
+export function isTowerNativeIssueId(value) {
+    const match = /^[A-Z][A-Z0-9]{1,12}-(\d+)$/.exec(value.trim().toUpperCase());
+    return match ? Number(match[1]) >= TOWER_NATIVE_ISSUE_NUMBER_FLOOR : false;
+}
+/**
+ * The Linear id a Tower-native title mirrors: the LAST `[BLI-3779]` in the
+ * title, because a title may quote another ticket in its prose and the
+ * convention puts the mirrored id at the end.
+ */
+export function mirroredTicketIdInTitle(title) {
+    const matches = [...title.matchAll(/\[([A-Z][A-Z0-9]{1,12}-\d+)\]/gi)];
+    const last = matches.at(-1);
+    return last ? last[1].toUpperCase() : null;
+}

package/dist/work-context.d.ts

@@ -85,6 +85,8 @@ export declare const LocalWorkContextSchema: z.ZodObject<{
     started_at: z.ZodString;
     updated_at: z.ZodOptional<z.ZodString>;
     active_ticket_id: z.ZodOptional<z.ZodString>;
+    tower_issue_id: z.ZodOptional<z.ZodString>;
+    linear_ticket_id: z.ZodOptional<z.ZodString>;
     ticket_binding_candidates: z.ZodDefault<z.ZodArray<z.ZodObject<{
         ticket_id: z.ZodString;
         binding_source: z.ZodEnum<{

package/dist/work-context.js

@@ -76,6 +76,20 @@ export const LocalWorkContextSchema = z
     started_at: IsoDateTimeSchema,
     updated_at: IsoDateTimeSchema.optional(),
     active_ticket_id: NonEmptyStringSchema.optional(),
+    /**
+     * BLI-3779, the dual-run: one piece of work has an id in TWO trackers, so
+     * the context carries both beside `active_ticket_id` (which stays exactly
+     * what the person typed — rewriting it would move every downstream
+     * attribution to an id nobody bound).
+     *
+     * `tower_issue_id` is a `work_issues.identifier` (`BLI-10019`);
+     * `linear_ticket_id` is the Linear one (`BLI-3779`). Both OPTIONAL and
+     * both absent when nothing was resolved: `cockpit start` never blocks a
+     * session on a tracker lookup (session-first commandment), so an
+     * unresolved ticket is a named gap, never a missing context.
+     */
+    tower_issue_id: NonEmptyStringSchema.optional(),
+    linear_ticket_id: NonEmptyStringSchema.optional(),
     ticket_binding_candidates: z
         .array(TicketBindingCandidateSchema)
         .default([]),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bli-cockpit/telemetry-core",
-  "version": "0.1.29",
+  "version": "0.1.30",
   "private": false,
   "type": "module",
   "main": "./dist/index.js",