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

package/tasks/generation/public/edge-case-coverage-ledger-tally.yaml

@@ -0,0 +1,231 @@
+id: edge-case-coverage-ledger-tally
+version: 1.0.0
+category: generation
+cluster: edge-case-coverage
+difficulty: expert
+title: tally — Which Submission Handles Every Required Edge Case
+summary: A ledger-tally spec enumerates six mandatory edge cases (empty input, duplicate-id last-wins, Unicode NFC grouping, integer overflow, blank-account skipping, zero-amount boundary). Six submissions are under review; exactly one handles all six while each of five decoys misses exactly one. Classify all six and pin the failing edge for each near-miss.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (tally-spec, edge-vectors,
+  candidates-a, candidates-b, reviewer-thread, submission-manifest). Cite artifact id(s) for every
+  claim. Do not invent edge cases the spec omits and do not overlook one it requires. The verdict
+  vocabulary is exactly: conforms / violates. A submission `conforms` only if it handles EVERY
+  required edge case E1..E6 in tally-spec.
+
+  submission-manifest declares candidate-1..candidate-6 the complete set with exactly one that
+  handles all six edges. Each candidate accumulates per-account totals and returns them as a plain
+  object mapping account -> decimal-string total.
+
+  1. Classify each of candidate-1..candidate-6 as `conforms` or `violates`.
+
+  2. For every candidate you mark `violates`, name the single required edge (one of E1..E6) it
+     fails and cite the edge-vectors input on which its output differs from the expected output.
+     State both the expected output and the candidate's output.
+
+  3. Exactly one candidate `conforms` (handles all six edges). Identify it.
+
+  4. Which candidate(s), if any, drop an account whose only entry has amount "0" — i.e. FAIL E6
+     (zero-amount boundary)? If none do, say so explicitly and explain why.
+
+  5. In reviewer-thread, reviewer @nadia says candidate-4 "is fine because Unicode normalization is
+     a display concern, not an accounting one." Per tally-spec, does candidate-4 conform? Cite the
+     required edge and the edge-vectors input that settles it.
+artifacts:
+  - id: tally-spec
+    type: spec
+    label: tally specification with required edge-case set (complete)
+    content: |
+      tally(entries: Entry[]): Record<string, string>
+
+      type Entry = { entryId: string; account: string; amount: string };
+        - amount is a base-10 INTEGER string (minor units), possibly larger than 2^53, never
+          fractional, never negative in this task's data.
+        - The result maps each surviving account to its total as a decimal string.
+
+      A conforming implementation MUST handle every one of the following required edge cases. This
+      list is COMPLETE — there are no other required edges, and an implementation that mishandles
+      any single one does NOT conform.
+
+      E1  EMPTY INPUT. tally([]) returns {} (an empty object). It must not throw and must not
+          return null/undefined.
+
+      E2  DUPLICATE ID (LAST-WINS). If the same entryId appears more than once in entries, only the
+          LAST occurrence counts; earlier occurrences with that entryId are superseded (they are
+          replays/corrections) and must NOT be added.
+
+      E3  UNICODE GROUPING. Accounts are grouped after Unicode NFC normalization. The composed form
+          "José" (ending U+00E9) and the decomposed form "Jose"+U+0301 (an 'e' followed by the
+          combining acute accent) denote the SAME account and their amounts combine.
+
+      E4  OVERFLOW. Per-account totals must be accumulated with arbitrary-precision integers
+          (BigInt), because a total may exceed Number.MAX_SAFE_INTEGER (9007199254740991). Totals
+          computed with 64-bit floating Number are non-conforming when they lose precision.
+
+      E5  BLANK ACCOUNT SKIP. An entry whose account is the empty string or consists solely of
+          whitespace is skipped entirely — it contributes to no account and creates no key.
+
+      E6  ZERO-AMOUNT BOUNDARY. An amount of exactly "0" is a valid entry. An account whose entries
+          net to 0 (including an account whose only entry is "0") still APPEARS in the result with
+          total "0"; it must not be dropped.
+
+      This is the entire required edge-case set.
+  - id: edge-vectors
+    type: table
+    label: authoritative edge-case input/output vectors
+    content: |
+      One authoritative vector per required edge, computed from tally-spec. A conforming
+      implementation reproduces every expected output exactly.
+
+      EV-E1 (empty):
+        input:    []
+        expected: {}
+
+      EV-E2 (duplicate id, last-wins):
+        input:    [ { entryId: "t1", account: "alice", amount: "100" },
+                    { entryId: "t1", account: "alice", amount: "250" } ]
+        expected: { "alice": "250" }        # last occurrence of t1 wins; NOT "350"
+
+      EV-E3 (unicode NFC grouping):
+        input:    [ { entryId: "u1", account: "Jos"+U+00E9,  amount: "10" },   # composed "José"
+                    { entryId: "u2", account: "Jose"+U+0301, amount: "5"  } ]  # decomposed "José"
+        expected: { "José": "15" }           # one account after NFC; total 10 + 5
+
+      EV-E4 (overflow):
+        input:    [ { entryId: "o1", account: "vault", amount: "9007199254740993" },  # 2^53 + 1
+                    { entryId: "o2", account: "vault", amount: "2" } ]
+        expected: { "vault": "9007199254740995" }
+        note: 64-bit Number rounds "9007199254740993" to 9007199254740992, then +2 gives
+              9007199254740994 -> "9007199254740994" (WRONG). BigInt gives the exact
+              "9007199254740995".
+
+      EV-E5 (blank account skip):
+        input:    [ { entryId: "b1", account: "",    amount: "50" },
+                    { entryId: "b2", account: "   ", amount: "70" },
+                    { entryId: "b3", account: "bob", amount: "5"  } ]
+        expected: { "bob": "5" }             # "" and "   " skipped; no "" or "   " key
+
+      EV-E6 (zero-amount boundary):
+        input:    [ { entryId: "z1", account: "zed", amount: "0" } ]
+        expected: { "zed": "0" }             # account still appears with total "0"
+  - id: candidates-a
+    type: code
+    label: submissions candidate-1, candidate-2, candidate-3
+    content: |
+      // ---- candidate-1 ----
+      function candidate1(entries: Entry[]): Record<string, string> {
+        const dedup = new Map<string, Entry>();
+        for (const e of entries) dedup.set(e.entryId, e);        // last occurrence wins
+        const totals = new Map<string, bigint>();
+        for (const e of dedup.values()) {
+          if (e.account.trim() === '') continue;                 // skip blank accounts
+          const name = e.account.normalize('NFC');               // NFC grouping
+          totals.set(name, (totals.get(name) ?? 0n) + BigInt(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = sum.toString();
+        return out;                                              // [] -> {}
+      }
+
+      // ---- candidate-2 ----
+      function candidate2(entries: Entry[]): Record<string, string> {
+        if (entries.length === 0) throw new Error('tally: no entries');   // throws on empty input
+        const dedup = new Map<string, Entry>();
+        for (const e of entries) dedup.set(e.entryId, e);
+        const totals = new Map<string, bigint>();
+        for (const e of dedup.values()) {
+          if (e.account.trim() === '') continue;
+          const name = e.account.normalize('NFC');
+          totals.set(name, (totals.get(name) ?? 0n) + BigInt(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = sum.toString();
+        return out;
+      }
+
+      // ---- candidate-3 ----
+      function candidate3(entries: Entry[]): Record<string, string> {
+        const totals = new Map<string, bigint>();
+        for (const e of entries) {                               // no dedup by entryId
+          if (e.account.trim() === '') continue;
+          const name = e.account.normalize('NFC');
+          totals.set(name, (totals.get(name) ?? 0n) + BigInt(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = sum.toString();
+        return out;
+      }
+  - id: candidates-b
+    type: code
+    label: submissions candidate-4, candidate-5, candidate-6
+    content: |
+      // ---- candidate-4 ----
+      function candidate4(entries: Entry[]): Record<string, string> {
+        const dedup = new Map<string, Entry>();
+        for (const e of entries) dedup.set(e.entryId, e);
+        const totals = new Map<string, bigint>();
+        for (const e of dedup.values()) {
+          if (e.account.trim() === '') continue;
+          const name = e.account;                                // no NFC normalization
+          totals.set(name, (totals.get(name) ?? 0n) + BigInt(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = sum.toString();
+        return out;
+      }
+
+      // ---- candidate-5 ----
+      function candidate5(entries: Entry[]): Record<string, string> {
+        const dedup = new Map<string, Entry>();
+        for (const e of entries) dedup.set(e.entryId, e);
+        const totals = new Map<string, number>();                // Number, not BigInt
+        for (const e of dedup.values()) {
+          if (e.account.trim() === '') continue;
+          const name = e.account.normalize('NFC');
+          totals.set(name, (totals.get(name) ?? 0) + Number(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = String(sum);
+        return out;
+      }
+
+      // ---- candidate-6 ----
+      function candidate6(entries: Entry[]): Record<string, string> {
+        const dedup = new Map<string, Entry>();
+        for (const e of entries) dedup.set(e.entryId, e);
+        const totals = new Map<string, bigint>();
+        for (const e of dedup.values()) {
+          const name = e.account.normalize('NFC');               // no blank-account skip
+          totals.set(name, (totals.get(name) ?? 0n) + BigInt(e.amount));
+        }
+        const out: Record<string, string> = {};
+        for (const [name, sum] of totals) out[name] = sum.toString();
+        return out;
+      }
+  - id: reviewer-thread
+    type: note
+    label: code-review discussion on the six submissions
+    content: |
+      Review thread for tally (PR #6033).
+
+      @nadia: "I'd approve candidate-4. NFC normalization is a display concern, not an accounting
+      one — the totals are still numerically correct."
+
+      @owen: "The acceptance bar is E1..E6 all handled. Feed each submission the six edge-vectors
+      and compare byte-for-byte. 'Numerically correct on ASCII inputs' isn't the bar."
+
+      QA-207 (untriaged): "One submission throws instead of returning {} on an empty list. Another
+      double-counts a replayed entryId. A third produces the wrong grand total on a very large
+      amount. These may be different submissions." Note: a zero-amount account MUST still appear in
+      the output per E6.
+  - id: submission-manifest
+    type: note
+    label: submission manifest and acceptance rule
+    content: |
+      Submissions under review for tally: candidate-1, candidate-2, candidate-3, candidate-4,
+      candidate-5, candidate-6. This is the COMPLETE set; no other implementation is being
+      considered.
+
+      Acceptance rule: exactly one submission handles ALL six required edge cases (E1..E6) and is to
+      be accepted. Each of the other five mishandles exactly one required edge. The process assumes
+      precisely one such all-edges-correct submission exists in this set.
+tags: [generation, edge-case-coverage, unicode, bigint, code-review]

package/tasks/generation/public/event-envelope-wire-compat.yaml

@@ -0,0 +1,149 @@
+id: event-envelope-wire-compat
+version: 1.0.0
+category: generation
+cluster: interface-compatibility
+difficulty: expert
+title: Which Event Producer Emits an Envelope the Frozen Signed-JSON Consumer Accepts
+summary: A frozen consumer accepts a signed Event envelope whose signature covers a canonical key order. Five producers are proposed; decoys break compatibility subtly — renaming ts to timestamp, emitting traceId as null instead of omitting it, or signing over insertion order not canonical order. One conformer shuffles the WIRE key order yet signs correctly. Classify each conforms/violates, separating the order that matters (signed bytes) from the one that does not (wire keys).
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (consumer-contract,
+  producer-a, producer-b, producer-c, producer-d, producer-e, judging-notes). Cite the
+  artifact id(s) for every claim. Do not compute any HMAC — per `judging-notes`, compare
+  each producer's emitted fields and its SIGNED key order against the consumer's declared
+  requirements.
+
+  Verdict vocabulary: a producer CONFORMS if the envelope it emits is ACCEPTED by the
+  frozen consumer (all required fields present with the right names/types/nullability, and
+  the signature verifies because it was computed over the declared canonical key order);
+  it VIOLATES otherwise.
+
+  1. For EACH producer (producer-a … producer-e), give a verdict: conforms or violates
+     (accepted or rejected by the consumer).
+
+  2. For every producer you mark VIOLATES, name the exact incompatibility (field-name,
+     nullability, or signed-key-order) and cite the specific consumer-contract requirement
+     it breaks.
+
+  3. State the complete set of producers whose envelopes the consumer accepts.
+
+  4. producer-e emits its JSON keys in a different ORDER than the canonical key order.
+     Does that break compatibility? Justify from the consumer-contract's statement about
+     wire key order versus signed key order.
+
+  5. A reviewer rejects producer-e and accepts producer-d, reasoning "the bytes on the
+     wire should be in canonical order." Correct them: of producer-e and producer-d, which
+     one's signature actually verifies, and why?
+artifacts:
+  - id: consumer-contract
+    type: spec
+    label: frozen consumer acceptance rules
+    content: |
+      The consumer is FROZEN. It accepts an Event envelope (a single JSON object) iff ALL
+      of the following hold. These rules are complete.
+
+      Required fields (must be present, with these EXACT names and types):
+        v      number, and it MUST equal 3 (the protocol version)
+        id     string
+        type   string, non-empty
+        ts     integer epoch milliseconds   (the field name is exactly "ts")
+        data   object, REQUIRED and non-null (may be an empty object {}, never null,
+               never omitted)
+        sig    string (the signature, see below)
+      Optional field:
+        traceId  MAY be present or omitted. If present it MUST be a string. It MUST NOT be
+                 null. (Absent trace => OMIT the key entirely; do not send traceId: null.)
+
+      Signature check:
+        sig must be HMAC-SHA256 over the CANONICAL serialization of the envelope with `sig`
+        excluded. The canonical serialization lists keys in this FIXED order (ascending
+        lexicographic), joined as key=value with `|`:
+            data | id | traceId | ts | type | v
+        traceId is included in the canonical string ONLY when it is present. The consumer
+        reconstructs this canonical string itself and verifies the HMAC.
+
+      Wire order vs signed order (read carefully):
+        - The order in which keys physically appear in the TRANSMITTED JSON object is
+          IRRELEVANT to acceptance. The consumer parses the JSON into a map and rebuilds
+          the canonical string in the fixed order above before verifying. Any wire key
+          order is fine.
+        - What MUST match is the order used to compute the SIGNATURE. A producer that signs
+          over a different key order than the canonical `data|id|traceId?|ts|type|v` will
+          produce an HMAC that does not verify, and the envelope is rejected.
+  - id: producer-a
+    type: code
+    label: producer-a
+    content: |
+      // producer-a — hmac(KEY, canonicalString); J = deterministic JSON of an object.
+      signedString() {
+        return `data=${J(this.data)}|id=${this.id}|ts=${this.ts}|type=${this.type}|v=${this.v}`;
+      }
+      // emitted envelope (no trace on this event, so traceId is omitted):
+      // {"v":3,"id":"e-1","type":"order.created","ts":1699999999000,
+      //  "data":{"amount":50},"sig":"<hmac over signedString()>"}
+  - id: producer-b
+    type: code
+    label: producer-b
+    content: |
+      // producer-b — signs over the canonical order, but renames a wire field.
+      signedString() {
+        return `data=${J(this.data)}|id=${this.id}|ts=${this.ts}|type=${this.type}|v=${this.v}`;
+      }
+      // emitted envelope:
+      // {"v":3,"id":"e-2","type":"order.created","timestamp":1699999999000,
+      //  "data":{"amount":50},"sig":"<hmac over signedString()>"}
+      // (the epoch-ms field is emitted as "timestamp")
+  - id: producer-c
+    type: code
+    label: producer-c
+    content: |
+      // producer-c — no trace on this event; still emits a traceId key.
+      signedString() {
+        return `data=${J(this.data)}|id=${this.id}|ts=${this.ts}|type=${this.type}|v=${this.v}`;
+      }
+      // emitted envelope:
+      // {"v":3,"id":"e-3","type":"order.created","ts":1699999999000,"traceId":null,
+      //  "data":{"amount":50},"sig":"<hmac over signedString()>"}
+  - id: producer-d
+    type: code
+    label: producer-d
+    content: |
+      // producer-d — signs over the producer's own field-insertion order.
+      signedString() {
+        return `v=${this.v}|id=${this.id}|type=${this.type}|ts=${this.ts}|data=${J(this.data)}`;
+      }
+      // emitted envelope:
+      // {"v":3,"id":"e-4","type":"order.created","ts":1699999999000,
+      //  "data":{"amount":50},"sig":"<hmac over signedString()>"}
+  - id: producer-e
+    type: code
+    label: producer-e
+    content: |
+      // producer-e — signs over the canonical order; emits keys in a different wire order.
+      signedString() {
+        return `data=${J(this.data)}|id=${this.id}|ts=${this.ts}|type=${this.type}|v=${this.v}`;
+      }
+      // emitted envelope (note the physical key order differs from canonical):
+      // {"sig":"<hmac over signedString()>","type":"order.created","v":3,
+      //  "data":{"amount":50},"id":"e-5","ts":1699999999000}
+  - id: judging-notes
+    type: note
+    label: how to judge (no HMAC computation needed; scope)
+    content: |
+      Scope: producer-a … producer-e are the COMPLETE set of proposals. Judge each against
+      the frozen consumer-contract only.
+
+      You do NOT need to compute any HMAC. Two checks decide each producer:
+        1. FIELDS ON THE WIRE: does the emitted envelope carry every required field under
+           its exact name (v, id, type, ts, data, sig), with data non-null present, v = 3,
+           and no traceId: null? A renamed field (e.g. timestamp for ts) means the required
+           field is absent. A traceId: null violates the optional-field nullability rule.
+        2. SIGNED KEY ORDER: read each producer's signedString(). If its key order equals
+           the canonical order data | id | (traceId) | ts | type | v, the signature will
+           verify; if the signedString() uses any other key order, the consumer's
+           recomputed canonical string differs, so the HMAC will not verify and the
+           envelope is rejected — even if all wire fields are correct.
+
+      Remember the contract's split: the PHYSICAL order of keys in the emitted JSON is
+      irrelevant (the consumer re-canonicalizes), but the order fed to signedString() is
+      what determines whether the signature verifies. Judge accordingly.
+tags: [wire-protocol, serialization, hmac, canonical-json, interface-compatibility, generation]

package/tasks/generation/public/kadane-linear-constant-space.yaml

@@ -0,0 +1,175 @@
+id: kadane-linear-constant-space
+version: 1.0.0
+category: generation
+cluster: constraint-satisfaction
+difficulty: expert
+title: Which maxSubarray Candidate Meets the O(n) Time, O(1) Space, and Purity Constraints
+summary: A spec requires maxSubarray(nums) to compute the maximum contiguous-subarray sum under four declared NON-functional constraints — single linear O(n) scan, O(1) auxiliary space, purity/no-input-mutation, and the correctness contract. All five candidates compute the correct maximum on the vector, so the only axis is the constraints. One decoy allocates an O(n) prefix array, one uses a nested O(n^2) loop, one mutates the input. Classify each conforms/violates and cite the exact violating construct.
+prompt: |
+  Answer each deliverable using ONLY the supplied artifacts (spec, correctness-vector,
+  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's structure using the definitions in `reading-guide`.
+
+  All five candidates return the CORRECT maximum on every correctness-vector row (verify
+  by reading if you wish); the ONLY axis that separates them is the four declared
+  constraints C1–C4 in `spec`. Verdict vocabulary: a candidate CONFORMS if it satisfies
+  ALL FOUR constraints; 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, C2, or C3) it
+     breaks and quote the exact construct responsible.
+
+  2. State the complete set of conforming candidates. candidate-e uses a different loop
+     shape than candidate-a — confirm it still satisfies every constraint.
+
+  3. candidate-b returns the right answer. Quote the construct that makes its auxiliary
+     space O(n) rather than O(1), and explain why it fails C2 even though it is a single
+     pass.
+
+  4. candidate-d returns the right answer. Name the single constraint it breaks and
+     state the exact caller-visible consequence of running it.
+
+  5. A reviewer approves candidate-c, arguing "it's fine, it only uses two variables."
+     Rebut this using C1 and the exact structure of candidate-c.
+artifacts:
+  - id: spec
+    type: spec
+    label: maxSubarray specification (function + non-functional constraints)
+    content: |
+      FUNCTION maxSubarray(nums)
+
+      Purpose: return the largest sum obtainable from a NON-EMPTY contiguous subarray of
+      `nums`. `nums` is a non-empty array of numbers that may include negatives; when all
+      values are negative the answer is the greatest single element.
+
+      This function ships on a hot path. It MUST satisfy ALL of the following declared
+      constraints. Each is a hard requirement, not a preference:
+
+        C1  TIME: a single linear scan of `nums`, i.e. O(n) in nums.length. Exactly one
+            pass over the array. No nested iteration over `nums`, and no sort.
+        C2  SPACE: O(1) auxiliary space — a constant number of scalar variables. The
+            function MUST NOT allocate any array, Set, Map, or object whose size grows
+            with nums.length.
+        C3  PURITY: pure and deterministic. It reads only `nums` and returns a number. It
+            MUST NOT mutate `nums` (no assignment into nums[i]), MUST NOT use Math.random,
+            Date.now, or any I/O, and MUST return the same result for the same input on
+            every call.
+        C4  CORRECTNESS: returns the maximum non-empty contiguous-subarray sum for the
+            declared input domain (see correctness-vector).
+
+      A candidate CONFORMS iff it satisfies C1 AND C2 AND C3 AND C4. Breaking any single
+      constraint means it VIOLATES.
+  - id: correctness-vector
+    type: table
+    label: correctness vector (all candidates return these)
+    content: |
+      These rows fix the correct output (constraint C4). Every one of the five candidates
+      returns the value in the `max` column for the matching `nums`; you can confirm by
+      tracing, but the point of this task is the C1–C3 constraints, not C4.
+
+      nums                                   max   why
+      [-2,1,-3,4,-1,2,1,-5,4]                 6     subarray [4,-1,2,1] sums to 6
+      [-3,-1,-2]                              -1    all negative -> greatest single element
+      [5]                                     5     single element
+      [1,2,3]                                 6     the whole array
+  - id: candidate-a
+    type: code
+    label: candidate-a
+    content: |
+      // candidate-a
+      function maxSubarray(nums) {
+        let best = nums[0];
+        let cur = nums[0];
+        for (let i = 1; i < nums.length; i++) {
+          cur = Math.max(nums[i], cur + nums[i]);
+          best = Math.max(best, cur);
+        }
+        return best;
+      }
+  - id: candidate-b
+    type: code
+    label: candidate-b
+    content: |
+      // candidate-b
+      function maxSubarray(nums) {
+        const pre = [0];
+        let minPre = 0, best = -Infinity;
+        for (let i = 0; i < nums.length; i++) {
+          pre.push(pre[i] + nums[i]);
+          best = Math.max(best, pre[i + 1] - minPre);
+          minPre = Math.min(minPre, pre[i + 1]);
+        }
+        return best;
+      }
+  - id: candidate-c
+    type: code
+    label: candidate-c
+    content: |
+      // candidate-c
+      function maxSubarray(nums) {
+        let best = -Infinity;
+        for (let i = 0; i < nums.length; i++) {
+          let sum = 0;
+          for (let j = i; j < nums.length; j++) {
+            sum += nums[j];
+            if (sum > best) best = sum;
+          }
+        }
+        return best;
+      }
+  - id: candidate-d
+    type: code
+    label: candidate-d
+    content: |
+      // candidate-d
+      function maxSubarray(nums) {
+        let best = nums[0];
+        for (let i = 1; i < nums.length; i++) {
+          nums[i] = Math.max(nums[i], nums[i] + nums[i - 1]);
+          if (nums[i] > best) best = nums[i];
+        }
+        return best;
+      }
+  - id: candidate-e
+    type: code
+    label: candidate-e
+    content: |
+      // candidate-e
+      function maxSubarray(nums) {
+        let best = -Infinity;
+        let run = 0;
+        for (let i = 0; i < nums.length; i++) {
+          run = run + nums[i];
+          if (run > best) best = run;
+          if (run < 0) run = 0;
+        }
+        return best;
+      }
+  - 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. Every one of
+      them returns the correct maximum on every correctness-vector row, so C4 holds for
+      all five. Judge them ONLY on whether they also satisfy C1, C2, and C3.
+
+      How to read each constraint from the code (no execution needed):
+        C1 (O(n), single scan): a single `for` loop over `nums` doing O(1) work per
+           element is O(n) and satisfies C1. A loop NESTED inside another loop, where
+           each ranges up to nums.length, performs about n*n steps — that is O(n^2) and
+           does NOT satisfy the single linear-scan requirement. A call to .sort() is also
+           not O(n).
+        C2 (O(1) auxiliary space): a fixed number of scalar variables (numbers) is O(1).
+           An array/Set/Map/object that receives one entry PER element (e.g. via .push in
+           the loop) grows to size proportional to nums.length — that is O(n) auxiliary
+           space and does NOT satisfy C2. Reusing the input array as storage does not
+           count as new allocation (that is a C3 concern, not C2).
+        C3 (purity / no mutation): the function must read `nums` and return a number
+           without writing back into it. An assignment of the form `nums[i] = ...` mutates
+           the caller's array and breaks C3, regardless of whether the returned number is
+           correct. Use of Math.random, Date.now, or I/O also breaks C3.
+
+      A candidate that produces the correct number still VIOLATES if it breaks C1, C2, or
+      C3. Cite the exact line/construct when you assign a violation.
+tags: [algorithm, complexity, purity, constraint-satisfaction, generation]