@sprigr/apps-fleet-conventions 0.1.0

package/README.md

@@ -0,0 +1,108 @@
+# @sprigr/apps-fleet-conventions
+
+The Sprigr dev-fleet's GitHub comment conventions as pure functions: how a
+tech-lead-reviewer verdict is written and parsed, and which half of the issue
+backlog each fixer agent owns.
+
+```bash
+npm install @sprigr/apps-fleet-conventions
+```
+
+No runtime dependencies. Everything is a regex or a small function over a
+comment body, an issue number, or an agent slug.
+
+## Why this package exists
+
+Two codebases gate real behaviour on these conventions: the sprigr-team
+platform (the merge gate in `packages/agent-core` and the fleet event router in
+`workers/provisioning`) and the `github` marketplace app. Each hand-synced copy
+of a regex has already failed in production once (sprigr-team#6334: two copies
+of the verdict pattern went blind together on a markdown-bolded APPROVE). This
+package is the single implementation. sprigr-team's `@sprigr/team-shared`
+depends on it and re-exports it, so the platform and the app run the same code.
+
+The sources are byte-for-byte ports of sprigr-team's
+`packages/shared/src/utils/fleet-verdict.ts` and `fleet-shard.ts`, plus
+`verdictNamedSha` from `packages/agent-core/src/tools/github-merge-gate.ts`.
+Their doc comments carry the incident history behind every rule and reference
+sprigr-team paths and issue numbers. Do not "tidy" a regex here without reading
+that history: each odd clause closes a measured hole.
+
+## The verdict convention
+
+The tech-lead-reviewer posts one machine-readable verdict per review round:
+
+```
+<!-- verdict sha=69acb41 -->
+[tech-lead-reviewer] VERDICT: APPROVE | one-line reason
+```
+
+- Line 1 is the **machine marker** `<!-- verdict sha=<7-char head SHA> -->`.
+  It names the PR head the reviewer looked at, which is what lets the merge
+  gate refuse an approval that predates the current head. Prose that merely
+  quotes a verdict never carries the marker.
+- Line 2 is the **identity prefix** `[tech-lead-reviewer]` followed by
+  `VERDICT:` and one ruling: `APPROVE`, `REQUEST_CHANGES` or `ESCALATE`.
+  Markdown emphasis (`**`, `_`), newlines and a leading heading are tolerated;
+  free prose between the prefix and `VERDICT:` is not. `REQUEST CHANGES` with a
+  space is folded to `REQUEST_CHANGES`.
+- `APPROVE` and `REQUEST_CHANGES` are actionable by the merge gate. `ESCALATE`
+  is a legitimate verdict for humans that the gate must fail closed on.
+
+### Exports (verdict)
+
+| export | what it is |
+| --- | --- |
+| `TECH_LEAD_VERDICT_RE` | Unanchored pattern for the two merge-actionable rulings. Use for "is there an APPROVE or REQUEST_CHANGES in this body". |
+| `TECH_LEAD_VERDICT_FORM_RE` | Anchored to the start of the body, admits `ESCALATE`. The post-time form check; never used to authorize a merge. |
+| `VERDICT_MARKER_RE` | Detects the machine marker anywhere in a body. |
+| `VERDICT_MARKER_STRIP_RE` | Strips a LEADING marker so a fresh one can be prepended. Anchored on purpose. |
+| `parseTechLeadVerdict(body)` | `'APPROVE' \| 'REQUEST_CHANGES' \| null` via the unanchored pattern. |
+| `parseAnchoredVerdictRuling(body)` | `TechLeadRuling \| null` via the anchored form pattern, so a quoted verdict later in the body can never be read as the comment's own ruling. |
+| `normalizeVerdictRuling(raw)` | Folds a captured ruling to canonical spelling (`REQUEST CHANGES` becomes `REQUEST_CHANGES`). |
+| `isUnparsedVerdictShaped(body)` | COUNT-ONLY: looks like a verdict but did not parse. Never gate on it. |
+| `isUnactionableRuling(body)` | Machine-form ruling the merge gate cannot act on (ESCALATE). The only shape a gate may fail closed on. |
+| `isMalformedVerdictPost(body)` | POST-TIME ONLY: opens as a reviewer comment, states `VERDICT:` near the top, and fails the form pattern. Refuse the post so the author finds out now. |
+| `verdictNamedSha(body)` | The head SHA a verdict names (marker first, then the `on head \`<sha>\`` prose form), lowercased, or `undefined`. |
+| `TechLeadVerdict`, `TechLeadRuling` | The ruling union types. |
+
+## The shard convention
+
+Since 2026-08-09 the fleet splits work by **issue-number parity** across every
+sprigr repo: the primary Dev Fixer (`dev-fixer`) owns ODD issue numbers, Dev
+Fixer B (`dev-fixer-b`) owns EVEN, and the two Issue Diagnosticians split the
+same way. Parity balances load about 50/50 and depends on nothing mutable:
+labels change, the number never does. Both halves still prioritise severity
+within their shard.
+
+### Exports (shard)
+
+| export | what it is |
+| --- | --- |
+| `issueShardParity(n)` | `'odd' \| 'even'`, or `null` for a non-integer. Callers must fail OPEN on `null` (show the item). |
+| `FLEET_SHARD_OWNERS` | `{ fixer: { odd, even }, diagnostician: { odd, even } }` agent slugs per parity. |
+| `shardParityForAgentSlug(slug)` | The parity an agent may work, or `null` for every agent outside the sharded fleet. Deliberately the two fixers only: the diagnosticians' step-0 recovery sweep is parity-exempt. |
+| `isInShard(n, parity)` | Whether an issue number is inside a shard. Unclassifiable numbers answer `true`. |
+| `ShardParity` | The parity type. |
+
+## Usage
+
+```ts
+import {
+  parseAnchoredVerdictRuling,
+  verdictNamedSha,
+  isMalformedVerdictPost,
+  shardParityForAgentSlug,
+  isInShard,
+} from '@sprigr/apps-fleet-conventions';
+
+const ruling = parseAnchoredVerdictRuling(comment.body); // 'APPROVE' | 'REQUEST_CHANGES' | 'ESCALATE' | null
+const reviewedHead = verdictNamedSha(comment.body);      // '69acb41' | undefined
+
+const parity = shardParityForAgentSlug(agentSlug);       // null for a normal company agent
+const visible = parity ? issues.filter((i) => isInShard(i.number, parity)) : issues;
+```
+
+Pin an exact version, as with every `@sprigr/apps-*` package: the marketplace
+build-runner runs a plain `npm install` per install build, so a caret range
+would roll a new version into production with no app change and no review.

package/dist/index.d.ts

@@ -0,0 +1,244 @@
+/**
+ * @sprigr/apps-fleet-conventions: tech-lead-reviewer verdict conventions.
+ *
+ * Ported byte-for-byte (apart from this header) from sprigr-team
+ * `packages/shared/src/utils/fleet-verdict.ts`, followed by `verdictNamedSha`
+ * and its pattern table from `packages/agent-core/src/tools/github-merge-gate.ts`,
+ * so the platform (`@sprigr/team-shared`) and the github marketplace app share
+ * one implementation instead of two hand-synced copies. The file paths named
+ * in the doc comments below point into sprigr-team, where the consumers live.
+ */
+/**
+ * The single source of truth for parsing tech-lead-reviewer verdict comments.
+ *
+ * Two consumers gate real behaviour on this pattern: the merge gate in
+ * packages/agent-core/src/tools/github-merge-gate.ts (`assertApprovalIsCurrent`) and the
+ * fleet event router in workers/provisioning/src/github-event-router.ts
+ * (verdict-posted wakes). They previously carried two hand-synced copies of
+ * the regex; both were blind to markdown emphasis, and both failed together
+ * on the same comment (#6334).
+ *
+ * History (#6334): the reviewer posted a genuine APPROVE written as
+ * `[tech-lead-reviewer]\n\n**VERDICT: APPROVE**`. The old
+ * `\[tech-lead-reviewer\]\s*VERDICT:` pattern matched the newlines but not
+ * the `**`, so the merge gate reported the older REQUEST_CHANGES as "most
+ * recent" and the router never fired a wake — a message that read exactly
+ * like a stale/forged-verdict attack and manufactured a critical-severity
+ * security escalation. No forgery occurred; the parser could not survive
+ * bold. The fix is parser tolerance, not dropping the machine format:
+ * `[\s*_]*` admits whitespace/newlines plus `*`/`_` emphasis markers between
+ * the identity prefix, `VERDICT:`, and the ruling word.
+ */
+declare const TECH_LEAD_VERDICT_RE: RegExp;
+/**
+ * The canonical machine marker the reviewer persona puts on the first line of
+ * every verdict (`<!-- verdict sha=<7-char head SHA> -->`). Comments carrying
+ * it are machine artifacts by contract, which is what makes post-time
+ * validation of them safe: prose that merely QUOTES a verdict never carries
+ * the marker.
+ */
+declare const VERDICT_MARKER_RE: RegExp;
+/**
+ * Strips a LEADING machine marker so a fresh one can be prepended in its
+ * place (`add_pull_request_comment`'s unconditional re-derive, #6482).
+ * Anchored to the start of the body on purpose: a marker that shows up
+ * later in the body — e.g. inside quoted prose from an earlier comment — is
+ * not "the" marker and must never be touched. Exported so every caller that
+ * needs to replace a marker uses this one definition instead of a hand-rolled
+ * copy that could drift out of anchor.
+ */
+declare const VERDICT_MARKER_STRIP_RE: RegExp;
+/**
+ * Post-time form check: like TECH_LEAD_VERDICT_RE but also admitting the
+ * ESCALATE ruling, which is a legitimate verdict for humans that the merge
+ * gate deliberately cannot act on. Used to validate a verdict body BEFORE
+ * posting; never used to authorize a merge.
+ *
+ * Anchored to the START of the body (#6484): an unanchored version matched
+ * `[tech-lead-reviewer] VERDICT: <ruling>` anywhere in the text, including
+ * prose that only QUOTES a verdict rather than stating one. Real proof case:
+ * comment 5454053747 on #6470 is a `[dev-fixer specialist]` STATUS NOTE whose
+ * body opens with that prefix, not `[tech-lead-reviewer]`, but quotes
+ * `` `[tech-lead-reviewer] VERDICT: APPROVE` `` mid-sentence while recapping
+ * the PR's comment trail — the unanchored pattern matched that quote and
+ * would have routed the note through the CI-gate/marker-attach path in
+ * `add_pull_request_comment` as if it were a real verdict. The allowed prefix
+ * is `(optional machine marker)(optional markdown heading)(optional leading
+ * emphasis)[tech-lead-reviewer]` — the marker and heading are real, observed
+ * reviewer habits that still precede the identity prefix at the true start of
+ * a body (see `VERDICT_MARKER_STRIP_RE` and the `HEADERED_VERDICT` fixture
+ * below); prose between `[tech-lead-reviewer]` and `VERDICT:` itself still
+ * fails to parse, unchanged from before.
+ *
+ * Round 2 (#6484): the first anchored cut above admitted the marker and the
+ * heading but not leading `**`/`_` emphasis directly on the identity prefix,
+ * which is a live reviewer habit and not a hypothetical — comments
+ * `5451246349` and `5451314888` on #6456 both open
+ * `<!-- verdict sha=69acb41 -->\n**[tech-lead-reviewer] VERDICT: …**` and fell
+ * out of the anchored form entirely. That silently re-opened the #6334 hole
+ * this pattern exists to close: `applyVerdictCiGate` passed the bolded body
+ * through untouched (no CI gate, no marker re-derive), and separately
+ * `isUnactionableRuling` stopped recognizing a bolded ESCALATE as a ruling the
+ * merge gate must fail closed on. `[*_]*` ahead of the prefix admits the
+ * emphasis the same way `[\s*_]*` already does between the prefix and
+ * `VERDICT:`, without loosening the anchor itself.
+ */
+declare const TECH_LEAD_VERDICT_FORM_RE: RegExp;
+type TechLeadVerdict = 'APPROVE' | 'REQUEST_CHANGES';
+/**
+ * Fold a captured ruling to its canonical spelling.
+ *
+ * Both patterns admit `REQUEST CHANGES` with a SPACE as well as the canonical
+ * `REQUEST_CHANGES`, so every capture must come through here before it is used
+ * or compared — `github-merge-gate.ts` casts the raw capture straight to the
+ * union type, which would otherwise put the literal string "REQUEST CHANGES"
+ * into a field typed `'REQUEST_CHANGES'` and make every later equality check
+ * silently false.
+ *
+ * Why admit the space at all rather than refusing it (#7653): measured over
+ * 60 h, 19 of 39 non-parsing reviewer comments differed from the contract by
+ * exactly this one character. It is unambiguous — no other ruling it could
+ * mean — and every consumer treats the two identically, so folding it is
+ * strictly safer than leaving those verdicts INVISIBLE to the merge gate,
+ * which is what the strict spelling was actually achieving. The canonical form
+ * stays `REQUEST_CHANGES` (scripts/seed-fleet-agents.ts) and is what every
+ * consumer sees; this only stops a separator from voiding a real ruling.
+ */
+declare function normalizeVerdictRuling(raw: string): TechLeadRuling;
+type TechLeadRuling = 'APPROVE' | 'REQUEST_CHANGES' | 'ESCALATE';
+/**
+ * Parse a comment body's ruling using the ANCHORED TECH_LEAD_VERDICT_FORM_RE
+ * pattern (admits ESCALATE), never the unanchored TECH_LEAD_VERDICT_RE.
+ *
+ * #6584 round 2: the duplicate-verdict backstop in
+ * packages/agent-core/src/tools/github.ts originally read both sides of the
+ * comparison with parseTechLeadVerdict (unanchored, APPROVE|REQUEST_CHANGES
+ * only). An ESCALATE comment that QUOTES the verdict it supersedes — e.g.
+ * "...supersedes my earlier `[tech-lead-reviewer] VERDICT: APPROVE` note" —
+ * has no APPROVE or REQUEST_CHANGES at the true start of its body, but the
+ * unanchored reader matched the quoted text anywhere in the string and
+ * reported the whole comment as APPROVE. That misclassified a non-terminal
+ * ESCALATE as the terminal ruling, which refused every later verdict on that
+ * head — reproducing the exact #6584 deadlock inside the escalation lane.
+ * This reader is anchored to the start of the body (same anchor as
+ * TECH_LEAD_VERDICT_FORM_RE itself), so a quote appearing later can never be
+ * mistaken for the comment's own ruling.
+ */
+declare function parseAnchoredVerdictRuling(body: string): TechLeadRuling | null;
+/** Parse a comment body into a verdict, or null if none parses. */
+declare function parseTechLeadVerdict(body: string): TechLeadVerdict | null;
+/**
+ * True when a body looks like a reviewer verdict but the strict pattern
+ * cannot parse a ruling out of it. COUNT-ONLY: built for reporting ("N
+ * comments look like verdicts but did not parse"), never for blocking or
+ * authorizing — the loose shape matches any reviewer note that merely says
+ * the word "verdict", and using it to block parked an already-approved PR in
+ * the #6367 round-2 measurement: 80 real comments replayed across 8 PRs,
+ * 2 blocked, 1 falsely (comment 5429229662 on #6344, a consult note posted
+ * after its own APPROVE). Source: the round-2 verdict on PR #6367, which
+ * records the PR list and per-comment results.
+ * A gate that finds any of these MUST say so in its output instead of
+ * reporting the newest PARSEABLE verdict as "the most recent verdict" —
+ * stating more than it measured is what escalated #6334 from a formatting
+ * bug to a security incident.
+ */
+declare function isUnparsedVerdictShaped(body: string): boolean;
+/**
+ * True when a body states a machine-form `VERDICT: <ruling>` whose ruling the
+ * merge gate cannot act on (today: ESCALATE TO A HUMAN). This is the ONLY
+ * shape a gate may fail closed on: it is a deliberate ruling in the machine
+ * format, not prose that happens to mention verdicts. Malformed rulings that
+ * fail even the FORM pattern are prevented at post time instead
+ * (add_pull_request_comment's marker validation).
+ */
+declare function isUnactionableRuling(body: string): boolean;
+/**
+ * POST-TIME ONLY: this body is trying to be a verdict and is malformed.
+ *
+ * True when the body opens as a reviewer comment AND states a `VERDICT:` line
+ * near the top AND does not match `TECH_LEAD_VERDICT_FORM_RE`. Used by
+ * `applyVerdictCiGate` to refuse the post outright, so the author learns at
+ * post time instead of the verdict being silently invisible to the merge gate
+ * for hours.
+ *
+ * NOT `isUnparsedVerdictShaped`, which its own docstring reserves for COUNTING
+ * and which must never gate: that one is unanchored (so it fires on any note
+ * quoting a verdict — measured, it flags four `[dev-fixer]` status notes here)
+ * and it reads with `parseTechLeadVerdict`, which does not admit ESCALATE, so
+ * gating on it would refuse legitimate ESCALATE verdicts. Both were measured
+ * against 95 live comments before this predicate was written (#7653).
+ *
+ * Fail-open by construction: a reviewer note that states no `VERDICT:` at all
+ * is a consult and passes untouched (11 of 39 non-parsing bodies in that
+ * sample), as does anything not opening with the reviewer's own prefix.
+ */
+declare function isMalformedVerdictPost(body: string): boolean;
+/** The head SHA a verdict names, from whichever form it used. */
+declare function verdictNamedSha(body: string): string | undefined;
+
+/**
+ * @sprigr/apps-fleet-conventions: the fleet's odd/even issue shard rule.
+ *
+ * Ported byte-for-byte (apart from this header) from sprigr-team
+ * `packages/shared/src/utils/fleet-shard.ts`, so the platform
+ * (`@sprigr/team-shared`) and the github marketplace app share one
+ * implementation. The file paths named in the doc comments below point into
+ * sprigr-team, where the consumers live.
+ */
+/**
+ * The single source of truth for the fleet's issue-number SHARD rule.
+ *
+ * Since 2026-08-09 the fleet splits work by issue-number PARITY across every
+ * sprigr repo: the primary Dev Fixer owns ODD, Dev Fixer B owns EVEN, and the
+ * two Issue Diagnosticians split the same way. Parity balances the load ~50/50,
+ * depends on nothing mutable (labels change, the number never does), and both
+ * halves still prioritise severity WITHIN their shard.
+ *
+ * Three surfaces need the rule and used to state it separately: the personas
+ * (prose), the fleet event router (`workers/provisioning/src/github-event-router.ts`),
+ * and now the `github` tool's `list_issues` candidate scan. This module is the
+ * one definition they share, in the same spirit as `fleet-verdict.ts`.
+ *
+ * WHY THE TOOL FILTERS AT ALL (sprigr-team#6581). The shard was enforced only
+ * by a model choosing to obey an instruction on each pick, and it was measured
+ * being violated in both directions: seven `fix/issue-*` branches (the ODD
+ * owner) opened on EVEN issues, and one `fixb/issue-*` branch on an ODD issue.
+ * #6598 was implemented twice as a result (PRs #6603 and #6604, the second
+ * discarded as a duplicate). Rewording the personas did not close it: the
+ * expired `(no shard test while you are the only fixer)` carve-out was deleted
+ * in PR #6648 and verified live, and a violation still landed 4h10m later.
+ * A wrong-parity issue the agent can see is a wrong-parity issue the agent can
+ * pick, so the fix is to keep it out of the candidate list.
+ */
+/** Which half of the fleet an issue number belongs to. */
+type ShardParity = 'odd' | 'even';
+/**
+ * The parity of an issue number. Non-integers are not issue numbers and have
+ * no shard; callers must fail OPEN on `null` (show the item) rather than hide
+ * something they could not classify.
+ */
+declare function issueShardParity(issueNumber: number): ShardParity | null;
+/** The agent slug that owns each parity, per family. */
+declare const FLEET_SHARD_OWNERS: {
+    readonly fixer: {
+        readonly odd: "dev-fixer";
+        readonly even: "dev-fixer-b";
+    };
+    readonly diagnostician: {
+        readonly odd: "issue-diagnostician-v2";
+        readonly even: "issue-diagnostician-b";
+    };
+};
+/**
+ * The parity an agent may work, or `null` for every agent outside the sharded
+ * fleet (which is almost all of them: a normal company agent must never have
+ * its issue list silently halved).
+ */
+declare function shardParityForAgentSlug(slug: string | null | undefined): ShardParity | null;
+/**
+ * Is this issue number inside `parity`'s shard? Unclassifiable numbers answer
+ * `true` (fail open) for the reason given on `issueShardParity`.
+ */
+declare function isInShard(issueNumber: number, parity: ShardParity): boolean;
+
+export { FLEET_SHARD_OWNERS, type ShardParity, TECH_LEAD_VERDICT_FORM_RE, TECH_LEAD_VERDICT_RE, type TechLeadRuling, type TechLeadVerdict, VERDICT_MARKER_RE, VERDICT_MARKER_STRIP_RE, isInShard, isMalformedVerdictPost, isUnactionableRuling, isUnparsedVerdictShaped, issueShardParity, normalizeVerdictRuling, parseAnchoredVerdictRuling, parseTechLeadVerdict, shardParityForAgentSlug, verdictNamedSha };

package/dist/index.js

@@ -0,0 +1,89 @@
+// src/verdict.ts
+var TECH_LEAD_VERDICT_RE = /\[tech-lead-reviewer\][\s*_]*VERDICT:[\s*_]*(APPROVE|REQUEST[_ ]CHANGES)/i;
+var VERDICT_MARKER_RE = /<!--\s*verdict\s+sha=/i;
+var VERDICT_MARKER_STRIP_RE = /^\s*<!--\s*verdict\s+sha=[^>]*-->\s*\n?/i;
+var VERDICT_SHAPED_RE = /\[tech-lead-reviewer\][\s\S]{0,80}?VERDICT/i;
+var TECH_LEAD_VERDICT_FORM_RE = /^(?:<!--\s*verdict\s+sha=[^>]*-->\s*\n?)?\s*(?:#{1,6}\s*)?[*_]*\[tech-lead-reviewer\][\s*_]*VERDICT:[\s*_]*(APPROVE|REQUEST[_ ]CHANGES|ESCALATE)/i;
+function normalizeVerdictRuling(raw) {
+  return raw.toUpperCase().replace(/\s+/g, "_");
+}
+function parseAnchoredVerdictRuling(body) {
+  const m = body.match(TECH_LEAD_VERDICT_FORM_RE);
+  return m ? normalizeVerdictRuling(m[1]) : null;
+}
+function parseTechLeadVerdict(body) {
+  const m = body.match(TECH_LEAD_VERDICT_RE);
+  return m ? normalizeVerdictRuling(m[1]) : null;
+}
+function isUnparsedVerdictShaped(body) {
+  return VERDICT_SHAPED_RE.test(body) && parseTechLeadVerdict(body) === null;
+}
+function isUnactionableRuling(body) {
+  return TECH_LEAD_VERDICT_FORM_RE.test(body) && parseTechLeadVerdict(body) === null;
+}
+var REVIEWER_ANCHOR_RE = /^(?:<!--\s*verdict\s+sha=[^>]*-->\s*\n?)?\s*(?:#{1,6}\s*)?[*_]*\[tech-lead-reviewer\]/i;
+var VERDICT_STATEMENT_WINDOW = 800;
+function isMalformedVerdictPost(body) {
+  if (!REVIEWER_ANCHOR_RE.test(body)) return false;
+  if (!/VERDICT:/i.test(body.slice(0, VERDICT_STATEMENT_WINDOW))) return false;
+  return !TECH_LEAD_VERDICT_FORM_RE.test(body);
+}
+var VERDICT_HEAD_SHA_PATTERNS = [
+  // Canonical machine marker. seed-fleet-agents.ts mandates it as the FIRST
+  // line of every verdict ("<!-- verdict sha=<7-char head SHA> -->") and calls
+  // it "what makes your verdict idempotent - every owed-a-verdict predicate
+  // keys on it". It was NOT read here, so the strong server-side comparison
+  // below was skipped for template-compliant verdicts and the weak
+  // committer-date fallback ran instead (#6054). Verified against four real
+  // verdict bodies on PRs #6063/#6092/#6087: none matched the prose form.
+  /<!--\s*verdict\s+sha=\s*`?([0-9a-f]{7,40})`?\s*-->/i,
+  // Prose form, kept for verdicts that spell it out ("First verdict on head
+  // `<sha>`" / "Round N of 2 on head `<sha>`").
+  /\bon head\s+`?([0-9a-f]{7,40})`?/i
+];
+function verdictNamedSha(body) {
+  for (const re of VERDICT_HEAD_SHA_PATTERNS) {
+    const m = body.match(re);
+    if (m?.[1]) return m[1].toLowerCase();
+  }
+  return void 0;
+}
+
+// src/shard.ts
+function issueShardParity(issueNumber) {
+  if (!Number.isInteger(issueNumber)) return null;
+  return Math.abs(issueNumber) % 2 === 1 ? "odd" : "even";
+}
+var FLEET_SHARD_OWNERS = {
+  fixer: { odd: "dev-fixer", even: "dev-fixer-b" },
+  diagnostician: { odd: "issue-diagnostician-v2", even: "issue-diagnostician-b" }
+};
+var SHARD_FILTERED_AGENT_SLUGS = {
+  [FLEET_SHARD_OWNERS.fixer.odd]: "odd",
+  [FLEET_SHARD_OWNERS.fixer.even]: "even"
+};
+function shardParityForAgentSlug(slug) {
+  if (!slug) return null;
+  return SHARD_FILTERED_AGENT_SLUGS[slug] ?? null;
+}
+function isInShard(issueNumber, parity) {
+  const own = issueShardParity(issueNumber);
+  return own === null || own === parity;
+}
+export {
+  FLEET_SHARD_OWNERS,
+  TECH_LEAD_VERDICT_FORM_RE,
+  TECH_LEAD_VERDICT_RE,
+  VERDICT_MARKER_RE,
+  VERDICT_MARKER_STRIP_RE,
+  isInShard,
+  isMalformedVerdictPost,
+  isUnactionableRuling,
+  isUnparsedVerdictShaped,
+  issueShardParity,
+  normalizeVerdictRuling,
+  parseAnchoredVerdictRuling,
+  parseTechLeadVerdict,
+  shardParityForAgentSlug,
+  verdictNamedSha
+};

package/package.json

@@ -0,0 +1,35 @@
+{
+  "name": "@sprigr/apps-fleet-conventions",
+  "version": "0.1.0",
+  "description": "Sprigr dev-fleet GitHub comment conventions: tech-lead verdict parsing and the odd/even issue shard rule",
+  "type": "module",
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    }
+  },
+  "scripts": {
+    "typecheck": "tsc --noEmit",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "build": "tsup src/index.ts --format esm --dts --out-dir dist --clean --tsconfig tsconfig.build.json",
+    "prepublishOnly": "npm run build"
+  },
+  "devDependencies": {
+    "typescript": "^5.6.0",
+    "vitest": "^2.0.0"
+  },
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/sprigr/sprigr-app-kit.git",
+    "directory": "packages/fleet-conventions"
+  },
+  "files": [
+    "dist",
+    "README.md"
+  ]
+}