bridgebench 3.1.0-alpha.0 → 3.1.0-alpha.2

package/tasks/generation/public/lower-bound-insertion-point.yaml

@@ -0,0 +1,176 @@
+id: lower-bound-insertion-point
+version: 1.0.0
+category: generation
+cluster: algorithmic-correctness
+difficulty: expert
+title: Which Candidate Computes the Leftmost Insertion Point on Every Declared Input
+summary: A specification defines lowerBound(a, target) — the leftmost sorted-insertion index — with a complete acceptance vector of inputs and exact expected outputs. Five candidate implementations are submitted; some are correct, some carry a classic off-by-one, wrong-branch, or wrong-contract defect. Classify each candidate conforms/violates by tracing it against the declared vector, and name the exact input that disproves each violator.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (spec, acceptance-vector,
+  candidate-a, candidate-b, candidate-c, candidate-d, candidate-e, judging-notes). Cite
+  the artifact id(s) for every claim. Do not execute anything — trace each candidate by
+  hand against the acceptance-vector rows, which give the exact expected output.
+
+  Verdict vocabulary: a candidate CONFORMS if it returns the exact expected value on
+  every acceptance-vector row and honors the full contract in `spec`; otherwise it
+  VIOLATES.
+
+  1. For EACH candidate (candidate-a … candidate-e), give a verdict: conforms or
+     violates. State the verdict for all five.
+
+  2. For every candidate you mark VIOLATES, name ONE acceptance-vector row (by its `a`
+     and `target`) that the candidate fails, and give the value it returns versus the
+     value `spec`/acceptance-vector requires. One row per violator is enough.
+
+  3. candidate-a and candidate-e are written very differently (iterative vs recursive).
+     State whether candidate-e is behaviorally equivalent to `spec` on the declared
+     input domain, and justify it from the code rather than from its resemblance to
+     candidate-a.
+
+  4. Of the violators, which single one would a careless reviewer most likely wave
+     through as correct, and what is the exact input that disproves it? Explain why it
+     survives the "easy" rows but fails.
+
+  5. State the complete set of conforming candidates.
+artifacts:
+  - id: spec
+    type: spec
+    label: lowerBound specification (complete contract)
+    content: |
+      FUNCTION lowerBound(a, target)
+
+      Inputs:
+        a       an array of numbers sorted in ASCENDING order. May contain duplicate
+                values. May be empty. a is NOT to be mutated.
+        target  a number.
+
+      Return:
+        The smallest index i in the CLOSED range [0, a.length] such that a[i] >= target.
+        Equivalently: the leftmost position at which `target` could be inserted to keep
+        `a` sorted, placing `target` BEFORE any elements equal to it.
+
+      Declared behavior on the boundaries (these are part of the contract, not examples):
+        - If a is empty, return 0.
+        - If every element of a is < target, no such i exists inside the array, so the
+          function returns a.length (the insertion point is the end).
+        - If target is <= a[0], return 0.
+        - If a contains values equal to target, return the index of the FIRST (leftmost)
+          such value.
+        - The return value is always an integer in [0, a.length]. The function NEVER
+          returns -1 or any sentinel; "not found" is not a concept here — every target
+          has an insertion point.
+
+      This is the complete contract. There is no separate "exact match" mode.
+  - id: acceptance-vector
+    type: table
+    label: complete acceptance vector (exact expected outputs)
+    content: |
+      This table is the COMPLETE acceptance set. A candidate conforms only if it returns
+      the exact expected value for EVERY row. Each row is (a, target) -> expected index.
+
+      row  a                target  expected
+      R1   []               5       0        # empty array -> 0
+      R2   [1,2,3]          0       0        # target below all -> 0
+      R3   [1,2,3]          5       3        # target above all -> a.length (end insert)
+      R4   [1,2,2,2,3]      2       1        # duplicates -> leftmost equal index
+      R5   [1,3]            2       1        # gap: first index with value >= 2 is index 1 (value 3)
+      R6   [2,4,6]          4       1        # exact match present once -> its index
+      R7   [1,2,3]          3       2        # exact match, leftmost >= 3 is index 2
+
+      Cross-check of the tricky rows:
+        R3: no element of [1,2,3] is >= 5, so the answer is the length, 3.
+        R4: [1,2,2,2,3], the first element >= 2 sits at index 1; indices 2 and 3 also
+            equal 2 but are NOT leftmost.
+        R7: [1,2,3], the first element >= 3 sits at index 2 (the value 3 itself).
+  - id: candidate-a
+    type: code
+    label: candidate-a
+    content: |
+      // candidate-a
+      function lowerBound(a, target) {
+        let lo = 0, hi = a.length;
+        while (lo < hi) {
+          const mid = lo + ((hi - lo) >> 1);
+          if (a[mid] < target) lo = mid + 1;
+          else hi = mid;
+        }
+        return lo;
+      }
+  - id: candidate-b
+    type: code
+    label: candidate-b
+    content: |
+      // candidate-b
+      function lowerBound(a, target) {
+        let lo = 0, hi = a.length;
+        while (lo < hi) {
+          const mid = lo + ((hi - lo) >> 1);
+          if (a[mid] <= target) lo = mid + 1;   // note the comparison
+          else hi = mid;
+        }
+        return lo;
+      }
+  - id: candidate-c
+    type: code
+    label: candidate-c
+    content: |
+      // candidate-c
+      function lowerBound(a, target) {
+        let lo = 0, hi = a.length - 1;           // note the initializer
+        while (lo < hi) {
+          const mid = lo + ((hi - lo) >> 1);
+          if (a[mid] < target) lo = mid + 1;
+          else hi = mid;
+        }
+        return lo;
+      }
+  - id: candidate-d
+    type: code
+    label: candidate-d
+    content: |
+      // candidate-d
+      function lowerBound(a, target) {
+        let lo = 0, hi = a.length - 1;
+        while (lo <= hi) {
+          const mid = (lo + hi) >> 1;
+          if (a[mid] === target) return mid;     // returns on any equal element
+          if (a[mid] < target) lo = mid + 1;
+          else hi = mid - 1;
+        }
+        return -1;                               // returned when no equal element exists
+      }
+  - id: candidate-e
+    type: code
+    label: candidate-e
+    content: |
+      // candidate-e
+      function lowerBound(a, target) {
+        const go = (lo, hi) => {
+          if (lo >= hi) return lo;
+          const mid = lo + Math.floor((hi - lo) / 2);
+          return a[mid] < target ? go(mid + 1, hi) : go(lo, mid);
+        };
+        return go(0, a.length);
+      }
+  - id: judging-notes
+    type: note
+    label: how to judge (scope and exhaustiveness)
+    content: |
+      Scope for this task:
+        - The five candidates above (candidate-a … candidate-e) are the COMPLETE set of
+          submissions. There are no other candidates.
+        - The acceptance-vector is the COMPLETE acceptance set: a candidate CONFORMS iff
+          it returns the exact expected index on every one of R1..R7 AND respects the
+          `spec` contract (never returns a sentinel, treats duplicates leftmost, inserts
+          at the end when target exceeds all elements). A candidate VIOLATES iff any row
+          fails or the contract is broken.
+        - `>> 1` is integer halving of a non-negative value; `mid = lo + ((hi - lo) >> 1)`
+          is the usual overflow-safe midpoint. All arithmetic here is on small arrays, so
+          you can trace exactly.
+        - JavaScript array indexing: reading a[i] for i >= a.length yields undefined, and
+          any comparison `undefined < x` or `undefined <= x` is false. You will not need
+          this for the conforming candidates, but note it when a loop bound is wrong.
+
+      Judge each candidate ONLY against this stated contract and vector. Do not credit a
+      candidate for being "close" or for passing the easy rows if it fails any row.
+tags: [algorithm, binary-search, correctness, algorithmic-correctness, generation]

package/tasks/generation/public/rolling-checksum-single-pass-pure.yaml

@@ -0,0 +1,186 @@
+id: rolling-checksum-single-pass-pure
+version: 1.0.0
+category: generation
+cluster: constraint-satisfaction
+difficulty: expert
+title: Which rollingChecksum Candidate Is Single-Pass, O(1)-Memory, Pure, and Reentrant
+summary: A spec defines a Fletcher-style rollingChecksum(bytes) under four declared constraints — single pass, bounded O(1) working memory, purity/reentrancy, and an exact arithmetic contract. Five candidates are submitted; one keeps a per-byte history array, one carries accumulators in module-level state so a second call drifts, one swaps the update order and computes the wrong value. Classify each conforms/violates, cite the exact construct, and give the concrete symptom of the reentrancy defect.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (spec, worked-example,
+  candidate-a, candidate-b, candidate-c, candidate-d, candidate-e, reading-guide). Cite
+  the artifact id(s) for every claim. Do not execute anything — reason about each
+  candidate from its code using the definitions in `reading-guide`, and trace the
+  arithmetic where a deliverable asks for a value.
+
+  Verdict vocabulary: a candidate CONFORMS if it satisfies ALL FOUR declared constraints
+  C1–C4 in `spec`; it VIOLATES if it breaks any one of them.
+
+  1. For EACH candidate (candidate-a … candidate-e), give a verdict: conforms or
+     violates. For every violator, name the exact constraint number (C1–C4) it breaks
+     and quote the exact construct responsible.
+
+  2. State the complete set of conforming candidates. candidate-e is written with
+     Array.prototype.reduce and allocates a small object each step — confirm whether it
+     still satisfies C1 and C2.
+
+  3. candidate-c returns the correct value on its FIRST invocation. Explain precisely why
+     it still VIOLATES its constraint, and give the concrete value a SECOND call with the
+     same input bytes [1,2] returns.
+
+  4. candidate-d — compute the value it returns for bytes [1,2], contrast it with the
+     spec's required 1027, and name the constraint it breaks.
+
+  5. A reviewer approves candidate-b, arguing "it's fine, it's still just one loop."
+     Rebut this using C2 and the exact growing structure in candidate-b.
+artifacts:
+  - id: spec
+    type: spec
+    label: rollingChecksum specification (function + constraints)
+    content: |
+      FUNCTION rollingChecksum(bytes)
+
+      `bytes` is an array of integers, each in 0..255. The function returns a 16-bit
+      checksum computed with two running accumulators, per this exact contract:
+
+        C4  CORRECTNESS: start a = 0, b = 0. For each element `byte` of `bytes`, in order:
+              a = (a + byte) % 255      (update a FIRST)
+              b = (b + a) % 255         (then fold the just-updated a into b)
+            After the loop, return  b * 256 + a.
+            Empty input returns 0.
+
+      This runs on a streaming hot path, so it MUST ALSO satisfy the following, each a
+      hard requirement:
+
+        C1  SINGLE PASS: it visits each element of `bytes` exactly once, in one loop (or
+            one reduce). No sort. It does not first materialize a second full-length copy
+            of the sequence and then iterate that.
+        C2  BOUNDED MEMORY: O(1) working memory — a constant number of accumulators (a
+            fixed-shape object with a constant field count also counts as O(1)). It MUST
+            NOT build an array/Set/Map that gains one entry per byte.
+        C3  PURE AND REENTRANT: the result depends ONLY on `bytes`. It MUST NOT read or
+            update module-level mutable state that carries between calls, MUST NOT use
+            Date.now / Math.random / I/O, and MUST NOT mutate `bytes`. Two calls with the
+            same `bytes` MUST return the same result.
+
+      A candidate CONFORMS iff it satisfies C1 AND C2 AND C3 AND C4. Breaking any single
+      constraint means it VIOLATES.
+  - id: worked-example
+    type: table
+    label: worked example and a reference trace
+    content: |
+      Reference computation of the contract (C4) so values are checkable by hand.
+
+      bytes = [1, 2]
+        start: a = 0, b = 0
+        byte 1: a = (0 + 1) % 255 = 1 ; b = (0 + 1) % 255 = 1
+        byte 2: a = (1 + 2) % 255 = 3 ; b = (1 + 3) % 255 = 4
+        return b * 256 + a = 4 * 256 + 3 = 1027
+
+      bytes = [10, 20, 30]
+        byte 10: a = 10 ; b = 10
+        byte 20: a = 30 ; b = 40
+        byte 30: a = 60 ; b = 100
+        return 100 * 256 + 60 = 25660
+
+      bytes = []      -> a = 0, b = 0 -> return 0
+
+      Note the ORDER inside the loop: a is updated first, and b folds in the NEW a. A
+      candidate that computes b from the OLD a (b before a) produces a different result.
+  - id: candidate-a
+    type: code
+    label: candidate-a
+    content: |
+      // candidate-a
+      function rollingChecksum(bytes) {
+        let a = 0, b = 0;
+        for (let i = 0; i < bytes.length; i++) {
+          a = (a + bytes[i]) % 255;
+          b = (b + a) % 255;
+        }
+        return b * 256 + a;
+      }
+  - id: candidate-b
+    type: code
+    label: candidate-b
+    content: |
+      // candidate-b
+      function rollingChecksum(bytes) {
+        let a = 0, b = 0;
+        const history = [];
+        for (let i = 0; i < bytes.length; i++) {
+          a = (a + bytes[i]) % 255;
+          b = (b + a) % 255;
+          history.push(b);
+        }
+        return b * 256 + a;
+      }
+  - id: candidate-c
+    type: code
+    label: candidate-c
+    content: |
+      // candidate-c
+      let _a = 0, _b = 0;               // module scope, outside the function
+      function rollingChecksum(bytes) {
+        for (let i = 0; i < bytes.length; i++) {
+          _a = (_a + bytes[i]) % 255;
+          _b = (_b + _a) % 255;
+        }
+        return _b * 256 + _a;
+      }
+  - id: candidate-d
+    type: code
+    label: candidate-d
+    content: |
+      // candidate-d
+      function rollingChecksum(bytes) {
+        let a = 0, b = 0;
+        for (let i = 0; i < bytes.length; i++) {
+          b = (b + a) % 255;             // folds in the OLD a
+          a = (a + bytes[i]) % 255;
+        }
+        return b * 256 + a;
+      }
+  - id: candidate-e
+    type: code
+    label: candidate-e
+    content: |
+      // candidate-e
+      function rollingChecksum(bytes) {
+        const acc = bytes.reduce(
+          (s, byte) => {
+            const a = (s.a + byte) % 255;
+            return { a, b: (s.b + a) % 255 };
+          },
+          { a: 0, b: 0 },
+        );
+        return acc.b * 256 + acc.a;
+      }
+  - id: reading-guide
+    type: note
+    label: how to read the constraints (definitions + scope)
+    content: |
+      Scope: candidate-a … candidate-e are the COMPLETE set of submissions. Judge each
+      against all four constraints C1–C4; do not assume correctness — trace the arithmetic
+      where it matters.
+
+      How to read each constraint from the code (no execution needed):
+        C1 (single pass): one `for` loop over bytes, or one `bytes.reduce(...)`, that
+           touches each element once is a single pass. Sorting or copying the whole array
+           into a second full-length structure before iterating is not.
+        C2 (bounded memory): a fixed set of number accumulators is O(1). A fixed-SHAPE
+           object with a constant number of fields (e.g. { a, b }) is also O(1), even if a
+           fresh one is created each step, because only a constant amount is live. An
+           array/Set/Map that receives one entry PER byte (e.g. via .push inside the loop)
+           grows to length proportional to bytes.length and is O(n) — that breaks C2.
+        C3 (pure and reentrant): the result must depend only on `bytes`. A `let`/`var`
+           declared at MODULE scope (outside the function body) that the function reads and
+           updates, and that is never reset per call, makes the output depend on PRIOR
+           calls — that breaks C3. Mutating `bytes`, or reading Date.now/Math.random, also
+           breaks C3. A quick test: if calling the function twice with identical `bytes`
+           can yield two different numbers, C3 is violated.
+        C4 (correctness): trace with a = 0, b = 0; per byte update a first, then b from the
+           new a; return b*256 + a. Computing b before updating a (using the stale a) gives
+           a different, wrong value.
+
+      Cite the exact line/construct when you assign a violation.
+tags: [checksum, streaming, purity, reentrancy, constraint-satisfaction, generation]

package/tasks/generation/public/spec-conformance-password-policy.yaml

@@ -0,0 +1,190 @@
+id: spec-conformance-password-policy
+version: 1.0.0
+category: generation
+cluster: spec-conformance
+difficulty: expert
+title: validatePassword — Ordered-Check Policy With One Conforming Submission
+summary: A password policy spec fixes six checks, an exact evaluation ORDER that decides which reason a multi-failure password returns, inclusive length boundaries, and exact reason tokens. Five submissions are under review; exactly one conforms. Classify all five, citing the single clause each near-miss breaks and the input that exposes it.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (policy-spec, test-vectors,
+  candidates-a, candidates-b, reviewer-thread, submission-manifest). Cite the artifact id(s) for
+  every claim. Do not add requirements the spec omits and do not ignore one it states. The verdict
+  vocabulary is exactly: conforms / violates.
+
+  policy-spec fixes clauses P1..P8 (six checks, an exact evaluation ORDER, and exact reason
+  tokens) and is the complete contract. submission-manifest declares candidate-1..candidate-5 the
+  entire set with exactly one conformer. Each candidate returns { ok: true } or
+  { ok: false, reason: <token> }.
+
+  1. Classify each of candidate-1..candidate-5 as `conforms` or `violates` against policy-spec.
+
+  2. For every candidate you mark `violates`, name the single clause (one of P1..P8) it breaks and
+     give one concrete password on which its returned object differs from the spec-correct object.
+     State both full objects.
+
+  3. Exactly one candidate `conforms`. Identify it and state the object it returns for the input
+     "Abcdefgh ijkl" (a 13-character string containing a space and no digit).
+
+  4. In reviewer-thread, reviewer @dmitri argues candidate-2 conforms because "it runs all six
+     checks and emits only the exact reason tokens." State candidate-2's verdict and cite the one
+     clause that refutes @dmitri, giving a password on which candidate-2 returns a DIFFERENT reason
+     than the spec (state both reasons).
+
+  5. For the valid 12-character password "Abcdefghij1k", exactly one candidate wrongly rejects it.
+     Name that candidate, the reason it returns, and the clause it breaks.
+artifacts:
+  - id: policy-spec
+    type: spec
+    label: validatePassword specification (frozen, complete)
+    content: |
+      validatePassword(pw: string): { ok: true } | { ok: false, reason: string }
+
+      Six checks, evaluated in a FIXED ORDER. The clauses below are the complete contract.
+
+      P1  LENGTH. Valid length is 12..64 characters INCLUSIVE. If pw.length < 12 the reason is
+          "too_short". If pw.length > 64 the reason is "too_long". (Exactly 12 and exactly 64 are
+          valid lengths.)
+
+      P2  LOWERCASE. pw must contain at least one [a-z]; otherwise reason "need_lower".
+
+      P3  UPPERCASE. pw must contain at least one [A-Z]; otherwise reason "need_upper".
+
+      P4  DIGIT. pw must contain at least one [0-9]; otherwise reason "need_digit".
+
+      P5  NO WHITESPACE. pw must contain no whitespace character (space, tab, newline — i.e. the
+          regex \s). If it contains any, reason "has_space".
+
+      P6  NO LONG RUN. pw must not contain any run of 3-or-more IDENTICAL consecutive characters
+          (e.g. "aaa"); otherwise reason "repeat_run".
+
+      P7  EVALUATION ORDER. The checks are applied in exactly this order and the FIRST failing check
+          determines the returned reason:
+              1) P1 length   2) P5 no-whitespace   3) P2 lowercase
+              4) P3 uppercase   5) P4 digit   6) P6 no-long-run
+          A password that fails several checks returns the reason of the earliest one in THIS order.
+          (Note: whitespace is checked before the character-class checks; length is checked first.)
+
+      P8  RESULT SHAPE. On success return exactly { ok: true } with NO reason field. On failure
+          return { ok: false, reason: <token> } where <token> is exactly one of:
+          "too_short", "too_long", "need_lower", "need_upper", "need_digit", "has_space",
+          "repeat_run". No other token, casing, spelling, or pluralization is permitted.
+
+      This is the entire specification.
+  - id: test-vectors
+    type: table
+    label: authoritative input/output vectors (spec-correct)
+    content: |
+      Authoritative outputs computed from policy-spec. A conforming implementation reproduces every
+      row exactly. (Objects shown as JSON.)
+
+      #  input                              expected output
+      -- ---------------------------------- ------------------------------------------
+      1  "Abcdefghij1k"      (12 chars)     { "ok": true }
+      2  "Abc1"              (4 chars)      { "ok": false, "reason": "too_short" }
+      3  "A" + "a".repeat(64) + "1"  (66)   { "ok": false, "reason": "too_long" }
+      4  "Abcdefgh ijkl"     (13 chars)     { "ok": false, "reason": "has_space" }
+      5  "Baaad12codeZ"      (12 chars)     { "ok": false, "reason": "repeat_run" }
+      6  "Abcdefghijkl"      (12 chars)     { "ok": false, "reason": "need_digit" }
+
+      Ordering notes (per P7):
+        - Row 3: the string also contains "aaa" (would trip P6) and is otherwise valid, but P1 is
+          checked FIRST, so the reason is "too_long", not "repeat_run".
+        - Row 4: "Abcdefgh ijkl" fails BOTH the whitespace check (P5) and the digit check (P4). Per
+          the P7 order, whitespace (position 2) precedes digit (position 5), so the reason is
+          "has_space", not "need_digit".
+        - Row 1: length is exactly 12 (valid, inclusive), has lower/upper/digit, no space, no run of
+          three -> { ok: true }.
+  - id: candidates-a
+    type: code
+    label: submissions candidate-1, candidate-2, candidate-3
+    content: |
+      // ---- candidate-1 ----
+      function candidate1(pw: string) {
+        if (pw.length < 12) return { ok: false, reason: 'too_short' };
+        if (pw.length > 64) return { ok: false, reason: 'too_long' };
+        if (/\s/.test(pw)) return { ok: false, reason: 'has_space' };
+        if (!/[a-z]/.test(pw)) return { ok: false, reason: 'need_lower' };
+        if (!/[A-Z]/.test(pw)) return { ok: false, reason: 'need_upper' };
+        if (!/[0-9]/.test(pw)) return { ok: false, reason: 'need_digit' };
+        if (/(.)\1\1/.test(pw)) return { ok: false, reason: 'repeat_run' };
+        return { ok: true };
+      }
+
+      // ---- candidate-2 ----
+      function candidate2(pw: string) {
+        if (pw.length < 12) return { ok: false, reason: 'too_short' };
+        if (pw.length > 64) return { ok: false, reason: 'too_long' };
+        if (!/[a-z]/.test(pw)) return { ok: false, reason: 'need_lower' };
+        if (!/[A-Z]/.test(pw)) return { ok: false, reason: 'need_upper' };
+        if (!/[0-9]/.test(pw)) return { ok: false, reason: 'need_digit' };
+        if (/\s/.test(pw)) return { ok: false, reason: 'has_space' };   // whitespace checked AFTER digit
+        if (/(.)\1\1/.test(pw)) return { ok: false, reason: 'repeat_run' };
+        return { ok: true };
+      }
+
+      // ---- candidate-3 ----
+      function candidate3(pw: string) {
+        if (pw.length <= 12) return { ok: false, reason: 'too_short' };  // rejects length exactly 12
+        if (pw.length > 64) return { ok: false, reason: 'too_long' };
+        if (/\s/.test(pw)) return { ok: false, reason: 'has_space' };
+        if (!/[a-z]/.test(pw)) return { ok: false, reason: 'need_lower' };
+        if (!/[A-Z]/.test(pw)) return { ok: false, reason: 'need_upper' };
+        if (!/[0-9]/.test(pw)) return { ok: false, reason: 'need_digit' };
+        if (/(.)\1\1/.test(pw)) return { ok: false, reason: 'repeat_run' };
+        return { ok: true };
+      }
+  - id: candidates-b
+    type: code
+    label: submissions candidate-4, candidate-5
+    content: |
+      // ---- candidate-4 ----
+      function candidate4(pw: string) {
+        if (pw.length < 12) return { ok: false, reason: 'too_short' };
+        if (pw.length > 64) return { ok: false, reason: 'too_long' };
+        if (/\s/.test(pw)) return { ok: false, reason: 'has_space' };
+        if (!/[a-z]/.test(pw)) return { ok: false, reason: 'need_lower' };
+        if (!/[A-Z]/.test(pw)) return { ok: false, reason: 'need_upper' };
+        if (!/[0-9]/.test(pw)) return { ok: false, reason: 'need_digit' };
+        // no run-of-three check
+        return { ok: true };
+      }
+
+      // ---- candidate-5 ----
+      function candidate5(pw: string) {
+        if (pw.length < 12) return { ok: false, reason: 'too_short' };
+        if (pw.length > 64) return { ok: false, reason: 'too_long' };
+        if (/\s/.test(pw)) return { ok: false, reason: 'has_space' };
+        if (!/[a-z]/.test(pw)) return { ok: false, reason: 'need_lower' };
+        if (!/[A-Z]/.test(pw)) return { ok: false, reason: 'need_upper' };
+        if (!/[0-9]/.test(pw)) return { ok: false, reason: 'needs_digit' };  // token spelled "needs_digit"
+        if (/(.)\1\1/.test(pw)) return { ok: false, reason: 'repeat_run' };
+        return { ok: true };
+      }
+  - id: reviewer-thread
+    type: note
+    label: code-review discussion on the five submissions
+    content: |
+      Review thread for validatePassword (PR #5120).
+
+      @dmitri: "candidate-2 runs all six checks — length, whitespace, lower, upper, digit,
+      run-of-three — and it only ever emits the exact reason tokens from P8. I think candidate-2
+      conforms."
+
+      @sara: "Running all six checks is not the same as running them in the spec's ORDER. P7 fixes
+      which reason wins when a password fails more than one check. Feed each submission a password
+      that fails TWO checks and compare the reason it returns to the spec's."
+
+      QA-141 (untriaged): "One submission rejects a password that is exactly 12 characters and
+      otherwise fully valid, reporting it as too_short. Per P1, length 12 is valid (inclusive)."
+  - id: submission-manifest
+    type: note
+    label: submission manifest and acceptance rule
+    content: |
+      Submissions under review for validatePassword: candidate-1, candidate-2, candidate-3,
+      candidate-4, candidate-5. This is the COMPLETE set; no other implementation is being
+      considered.
+
+      Acceptance rule: exactly one submission conforms to policy-spec on every input (it reproduces
+      all six test-vectors rows and obeys P1..P8 generally) and is to be accepted. The process
+      assumes precisely one conformer exists in this set.
+tags: [generation, spec-conformance, validation, code-review]