bridgebench 3.1.0-alpha.0

package/tasks/reasoning/public/counterexample-authorization-rule.yaml

@@ -0,0 +1,278 @@
+id: counterexample-authorization-rule
+version: 2.0.0
+category: reasoning
+cluster: formal-counterexample
+difficulty: expert
+title: Vault Access Policy Rewrite Equivalence and the Admin Fast-Path Audit
+summary: A team claims its optimized authorization evaluator is behavior-equivalent to the written Vault Access Policy and only short-circuits administrators earlier. Decide whether the equivalence holds across three code modules, and if not produce a minimal counterexample, isolate the diverging spec clause and code line, state the weakest precondition that repairs it, adjudicate three reviewer objections, and judge whether a proposed patch restores equivalence.
+prompt: |
+  A permissions team refactored an access evaluator for a document vault. They assert the new
+  evaluator in evaluate.ts is behavior-equivalent to the authoritative Vault Access Policy v4 for
+  every possible request, differing only in that administrators take a faster path. Three reviewers
+  filed objections and a fourth proposed a patch. You must adjudicate the equivalence rigorously.
+
+  A request is a record of attributes. The authoritative decision is defined only by the policy
+  (the spec), not by any code. Treat the three code modules as the shipped implementation, and the
+  fixtures and ops-samples as observed behavior of that implementation.
+
+  Deliverables (answer every one, and show the derivation that supports it):
+
+  1. Does the equivalence claim hold for all requests? Answer yes or no.
+
+  2. If it does not hold, give a single concrete minimal counterexample: an explicit assignment of
+     every attribute that matters, the decision the policy requires, and the decision the shipped
+     code produces. Trace the code decision step by step through evaluate.ts, and (where reached)
+     eligibility.ts and restrictions.ts, showing which branch is taken at each line. State which
+     attributes are irrelevant to the counterexample and why.
+
+  3. Name the exact policy clause and the exact code line that diverge, and state the direction of
+     the error: does the code over-grant or over-deny relative to the policy, and what is the
+     security consequence?
+
+  4. Give the weakest precondition on the request under which the shipped administrator branch
+     already agrees with the policy, and state the minimal code change that makes the evaluator
+     equivalent to the policy for all requests. Justify the minimality.
+
+  5. Adjudicate the three reviewer objections in reviewer-notes (R1 the clearance comparison, R2
+     administrators opening locked resources, R3 guests denied despite clearance). For each, say
+     whether it is a real divergence from the policy, and justify from the spec and the code.
+
+  6. Does the patch in proposed-patch restore full equivalence to the policy? If not, give a second
+     concrete counterexample on which the patched code still disagrees with the policy, and name the
+     exact line the patch got wrong.
+artifacts:
+  - id: policy
+    type: spec
+    label: Vault Access Policy v4 (authoritative semantics)
+    content: |
+      Vault Access Policy v4. A read request carries these attributes:
+        isAdmin        boolean          principal holds the administrator role
+        role           editor|viewer|guest   principal's non-admin role (ignored when isAdmin)
+        isOwner        boolean          principal is the resource owner
+        clearance      integer 0..3     principal clearance level
+        classification integer 0..3     resource classification level
+        locked         boolean          an editorial lock is set on the resource
+        legalHold      boolean          the resource is under legal hold
+        network        corp|vpn|public  origin network of the request
+        mfa            boolean          this session completed multi-factor authentication
+
+      The authoritative decision is:
+
+        ALLOW  if and only if  Eligible(req) AND NOT Restricted(req)
+
+      Eligibility (may this principal read this resource at all):
+
+        Eligible(req) =
+          isAdmin
+          OR ( clearance >= classification
+               AND ( isOwner OR role == 'editor' OR role == 'viewer' ) )
+
+        Clarifications:
+          - The clearance test is "greater than or equal": clearance 2 may read classification 2.
+          - A plain guest (role guest, not the owner) is never eligible unless isAdmin. Guests are
+            eligible only for resources they own (and only if clearance >= classification).
+          - Ownership substitutes for a reader role: an owner with sufficient clearance is eligible
+            regardless of role.
+
+      Restrictions (hard overrides that block an otherwise-eligible principal). ANY true restriction
+      denies the request:
+
+        R-HOLD   legalHold is set  ->  DENY for every principal, administrators included.
+                 Legal hold overrides all roles; there is NO administrator exemption from it. This
+                 is a compliance control: while a resource is under legal hold, no one reads it
+                 through this evaluator, not even an administrator.
+        R-LOCK   locked is set AND the principal is NOT an administrator  ->  DENY.
+                 Administrators ARE exempt from the editorial lock; non-administrators are not.
+        R-NET    network == 'public' AND NOT mfa  ->  DENY for every principal, administrators
+                 included. A public-network session without MFA is always denied.
+
+      Precedence: restrictions override eligibility. Being an administrator satisfies eligibility
+      and waives only R-LOCK. It does NOT waive R-HOLD and does NOT waive R-NET.
+
+      Worked decisions (authoritative):
+        W1 isAdmin=T, legalHold=T, network=corp, mfa=T, locked=F:
+           Eligible=T (admin). Restricted: R-HOLD true. ALLOW = T AND NOT T = DENY.
+        W2 isAdmin=T, legalHold=F, network=public, mfa=F:
+           Eligible=T. Restricted: R-NET true. ALLOW = DENY.
+        W3 isAdmin=T, legalHold=F, locked=T, network=corp, mfa=T:
+           Eligible=T. Restricted: R-HOLD F, R-LOCK (locked AND not admin)=F, R-NET F. ALLOW.
+        W4 role=viewer, clearance=1, classification=2:
+           Eligible: 1>=2 is false, so NOT eligible. DENY (restrictions not even reached).
+        W5 role=guest, isOwner=F, clearance=3, classification=0:
+           Eligible: 3>=0 true AND (isOwner F OR guest-is-not-editor/viewer F) = false. DENY.
+        W6 role=editor, clearance=3, classification=1, locked=T, network=vpn, mfa=T, isOwner=F:
+           Eligible=T. Restricted: R-LOCK (locked AND not admin)=T. DENY.
+  - id: eligibility
+    type: code
+    label: authz/eligibility.ts (Eligible, with request shape)
+    content: |
+      // authz/types.ts (shown here for reference)
+      export type Role = 'editor' | 'viewer' | 'guest';
+      export type Network = 'corp' | 'vpn' | 'public';
+      export interface AccessRequest {
+        isAdmin: boolean;
+        role: Role;            // ignored when isAdmin is true
+        isOwner: boolean;
+        clearance: number;     // 0..3
+        classification: number; // 0..3
+        locked: boolean;
+        legalHold: boolean;
+        network: Network;
+        mfa: boolean;
+      }
+      export interface Decision { allow: boolean; }
+
+      // authz/eligibility.ts
+      // Base eligibility only ("who may read this resource at all"). Restrictions are separate and
+      // are applied by evaluate.ts, never here.
+      import type { AccessRequest } from './types';
+
+      export function eligible(req: AccessRequest): boolean {
+        if (req.isAdmin) return true;                       // admins are always eligible
+        if (req.clearance < req.classification) return false; // below clearance: never eligible
+        const canRead = req.role === 'editor' || req.role === 'viewer';
+        return req.isOwner || canRead;                      // owner OR a reader role
+      }
+  - id: restrictions
+    type: code
+    label: authz/restrictions.ts (Restricted)
+    content: |
+      // authz/restrictions.ts
+      // Hard overrides. Any true value blocks the request. Evaluation order is irrelevant because
+      // the function is a disjunction; each clause is independent.
+      import type { AccessRequest } from './types';
+
+      export function restricted(req: AccessRequest): boolean {
+        if (req.legalHold) return true;                         // R-HOLD: applies to EVERYONE, admins too
+        if (req.locked && !req.isAdmin) return true;            // R-LOCK: blocks non-admins only
+        if (req.network === 'public' && !req.mfa) return true;  // R-NET: applies to EVERYONE, admins too
+        return false;
+      }
+
+      // Note for reviewers: restricted() alone is a faithful encoding of R-HOLD, R-LOCK, R-NET.
+      // Whether the shipped evaluator actually consults it on every path is a separate question.
+  - id: evaluate
+    type: code
+    label: authz/evaluate.ts (shipped evaluator with administrator fast path)
+    content: |
+      // authz/evaluate.ts
+      import { eligible } from './eligibility';
+      import { restricted } from './restrictions';
+      import type { AccessRequest, Decision } from './types';
+
+      export function decide(req: AccessRequest): Decision {
+        // Fast path: administrators are always eligible and bypass the editorial lock, so we skip
+        // eligibility() and the R-LOCK check for them and answer immediately.
+        if (req.isAdmin) {
+          if (req.network === 'public' && !req.mfa) return { allow: false };
+          return { allow: true };
+        }
+        if (!eligible(req)) return { allow: false };
+        return { allow: !restricted(req) };
+      }
+
+      // Batch auditor used to generate ops-samples. Pure; performs no I/O beyond returning rows.
+      export function auditAll(reqs: AccessRequest[]): Array<{ req: AccessRequest; shipped: Decision }> {
+        return reqs.map((req) => ({ req, shipped: decide(req) }));
+      }
+  - id: fixtures
+    type: table
+    label: Regression fixtures (all currently passing under the shipped code)
+    content: |
+      Each row is an input and the decision the policy requires. The shipped suite is GREEN: shipped
+      decide() matches the "policy" column on every row below. Boolean columns use T/F. A dash means
+      the attribute is unread on that row's code path.
+
+      No fixture sets an administrator together with legalHold=T. That combination is uncovered by
+      the suite, which is why the suite stays green despite the behavior in question.
+
+      #  | isAdmin | role   | clr | cls | owner | locked | hold | net    | mfa | policy
+      1  | T       | -      |  -  |  -  |  -    | F      | F    | corp   |  T  | ALLOW
+      2  | T       | -      |  -  |  -  |  -    | T      | F    | corp   |  T  | ALLOW
+      3  | T       | -      |  -  |  -  |  -    | F      | F    | public |  F  | DENY
+      4  | F       | editor |  2  |  2  | F     | F      | F    | corp   |  T  | ALLOW
+      5  | F       | viewer |  1  |  2  | F     | F      | F    | corp   |  T  | DENY
+      6  | F       | guest  |  2  |  1  | T     | F      | F    | corp   |  T  | ALLOW
+      7  | F       | editor |  3  |  1  | F     | T      | F    | vpn    |  T  | DENY
+      8  | F       | viewer |  3  |  0  | F     | F      | F    | public |  F  | DENY
+      9  | F       | guest  |  3  |  0  | F     | F      | F    | corp   |  T  | DENY
+      10 | F       | editor |  2  |  2  | F     | F      | F    | public |  T  | ALLOW
+      11 | F       | viewer |  0  |  0  | F     | F      | T    | corp   |  T  | DENY
+      12 | T       | -      |  -  |  -  |  -    | T      | F    | vpn    |  T  | ALLOW
+
+      Coverage note: rows 11 exercises legalHold only for a NON-admin (correctly denied). No row
+      pairs isAdmin=T with legalHold=T, so the administrator branch's handling of legal hold is
+      never asserted.
+  - id: ops-samples
+    type: table
+    label: Production decision samples (as emitted by the shipped evaluator via auditAll)
+    content: |
+      Sampled from the live evaluator. The "shipped" column is what decide() returned in production.
+      It is NOT necessarily what the policy requires; deriving the policy decision per row and
+      comparing is the point of the exercise. Boolean columns use T/F.
+
+      #  | isAdmin | role   | clr | cls | owner | locked | hold | net    | mfa | shipped
+      A  | T       | -      |  -  |  -  |  -    | F      | F    | corp   |  T  | ALLOW
+      B  | F       | editor |  2  |  2  | F     | F      | F    | corp   |  T  | ALLOW
+      C  | F       | viewer |  1  |  2  | F     | F      | F    | corp   |  T  | DENY
+      D  | T       | -      |  -  |  -  |  -    | F      | T    | corp   |  T  | ALLOW
+      E  | F       | editor |  3  |  1  | F     | T      | F    | vpn    |  T  | DENY
+      F  | T       | -      |  -  |  -  |  -    | T      | F    | corp   |  T  | ALLOW
+      G  | F       | guest  |  2  |  1  | T     | F      | F    | corp   |  T  | ALLOW
+      H  | T       | -      |  -  |  -  |  -    | F      | F    | public |  F  | DENY
+      I  | T       | -      |  -  |  -  |  -    | T      | T    | vpn    |  T  | ALLOW
+      J  | F       | guest  |  3  |  0  | F     | F      | F    | corp   |  T  | DENY
+
+      Analyst annotations (unverified hunches, not policy findings):
+        - Rows E and F both involve locked resources but differ in outcome. An analyst flagged this
+          as "inconsistent locking." Check whether it actually contradicts the policy.
+        - Row J denies a guest with the highest clearance. An analyst called this "a clearance bug."
+        - Rows D and I both set legalHold=T on an administrator and returned ALLOW. No analyst
+          flagged these, because the reviewers assumed the admin path was trivially correct.
+  - id: reviewer-notes
+    type: note
+    label: Review thread and objections
+    content: |
+      Claim under review (the equivalence claim): authz/evaluate.ts decide() is behavior-equivalent
+      to Vault Access Policy v4 for ALL requests; it merely short-circuits administrators before
+      computing eligibility. A prior static audit "found no divergence," which increased the team's
+      confidence in the claim. Treat that prior audit as unproven.
+
+      Three objections were filed against the claim. None is guaranteed correct:
+
+        R1 (clearance): "eligibility.ts uses clearance >= classification. Read access should require
+        strictly higher clearance than the resource classification, so `>=` over-grants by one level
+        and diverges from the policy." The filer wants the comparison changed to strict `>`.
+
+        R2 (lock bypass): "The administrator fast path returns allow even when locked is true, so an
+        administrator can open a locked resource (see ops-sample F). That looks like a lock-bypass
+        defect the old evaluator would not have permitted."
+
+        R3 (guest): "A guest with clearance 3 reading a classification-0 resource is denied (see
+        ops-sample J and fixture 9). Denying a fully-cleared guest looks too strict to be intended;
+        this must be an eligibility bug."
+
+      A fourth engineer attached a fix; see proposed-patch. Decide the equivalence claim on the
+      merits of the policy first, then judge R1, R2, R3, and the patch. Do not assume any objection,
+      analyst annotation, or the prior audit is correct.
+  - id: proposed-patch
+    type: diff
+    label: Proposed patch to authz/evaluate.ts
+    content: |
+      Proposed change to the administrator fast path in authz/evaluate.ts:
+
+         export function decide(req: AccessRequest): Decision {
+           if (req.isAdmin) {
+      -      if (req.network === 'public' && !req.mfa) return { allow: false };
+      +      if (req.legalHold) return { allow: false };
+             return { allow: true };
+           }
+           if (!eligible(req)) return { allow: false };
+           return { allow: !restricted(req) };
+         }
+
+      Author's note: "This makes administrators respect legal hold, which resolves the reported
+      production sample (D). Equivalence restored. I considered instead deleting the fast path and
+      letting admins fall through to `!restricted(req)`, but this one-line change looked smaller and
+      lower-risk, so I went with it."
+tags: [boolean-logic, authorization, formal-verification, counterexample, access-control]

package/tasks/reasoning/public/counterexample-scheduler-starvation.yaml

@@ -0,0 +1,290 @@
+id: counterexample-scheduler-starvation
+version: 2.0.0
+category: reasoning
+cluster: formal-counterexample
+difficulty: expert
+title: FairShare Scheduler Aging Invariant and the Reindex Wait-Clock Reset
+summary: A scheduler team claims its priority-aging design is starvation-free with a concrete wait bound. The aging code is present, the unit suite is green, yet a low-priority job never runs in production. Decide whether the shipped scheduler satisfies the claimed invariant, and if not produce the shortest concrete starvation trace, isolate the diverging spec clause and code line, and judge whether a proposed force-run patch fixes it.
+prompt: |
+  FairShare Scheduler v2 is a single-core tick scheduler. Its design uses priority aging so that a
+  low-priority job cannot be starved forever by a stream of higher-priority arrivals. The team
+  claims a starvation-free invariant with a concrete wait bound (see claim). The aging code is
+  present and the unit suite is green, but in production one low-priority job never runs while
+  higher-priority jobs keep cycling.
+
+  You are given the authoritative semantics (spec), the shipped implementation across two modules
+  (queue.ts, scheduler.ts), the green unit fixtures, a recorded production run (observed-run), a
+  finer-grained debug log (scheduler-debug), the claimed invariant with two on-call theories, and a
+  proposed patch. The authoritative behavior is defined by the spec, not by the code.
+
+  Deliverables (answer every one, with the derivation that supports it):
+
+  1. Does the shipped scheduler satisfy the claimed starvation-free invariant and its wait bound?
+     Answer yes or no.
+
+  2. If not, give the shortest concrete counterexample: an explicit arrival sequence (which jobs,
+     with which base priorities, arrive at which ticks), then a step-by-step trace of enough ticks
+     to prove that one specific job's wait never ends. At each tick show the ready-queue contents,
+     each job's enqueuedAt and effective priority, and which job is selected.
+
+  3. Contrast: run the SAME arrival sequence under the intended aging semantics from the spec. State
+     the exact tick at which the starved job would run, and the wait bound the spec guarantees.
+
+  4. Name the exact spec clause and the exact code line that diverge.
+
+  5. Give the weakest precondition on the ready queue under which the shipped reindex step changes
+     no scheduling decision, and state the minimal code change that restores the invariant for all
+     inputs.
+
+  6. Does the patch in proposed-patch fix the starvation? If not, run the same arrival sequence
+     under the patched code far enough to show the job still starves, and name the offending line.
+artifacts:
+  - id: spec
+    type: spec
+    label: FairShare Scheduler v2 semantics and the aging rule
+    content: |
+      FairShare Scheduler v2. Discrete ticks t = 0, 1, 2, ... A single ready queue holds jobs.
+      Each job j has an integer base priority basePriority(j) (higher is more urgent) and a field
+      enqueuedAt(j).
+
+      Arrivals. Zero or more new jobs may arrive at every tick, before selection. There is no upper
+      bound on arrivals; a saturating stream (a new job every tick, forever) is a legal input.
+
+      Enqueue and the wait clock. When a job enters the ready queue, enqueuedAt(j) is set once to
+      the current tick and is NOT modified while the job remains ready. The job's wait is
+      wait(j, t) = t - enqueuedAt(j); because enqueuedAt is never changed while the job is queued,
+      wait is monotonically non-decreasing until the job is selected.
+
+      Aging and effective priority. With aging step AGE_STEP (a positive integer, configured to 4):
+        effective(j, t) = basePriority(j) + floor( wait(j, t) / AGE_STEP )
+      A job's effective priority rises by one for every AGE_STEP ticks it has waited.
+
+      Selection. At each tick, after arrivals are inserted, run exactly one job: the ready job with
+      the greatest effective priority. Ties are broken FIFO, by the smallest enqueuedAt. The
+      selected job runs to completion within that tick and leaves the queue. Unselected jobs remain
+      ready and keep their enqueuedAt.
+
+      Claimed consequence. Let P_MAX be the maximum base priority ever present. A ready job with
+      base priority p has effective priority at least p + floor(wait / AGE_STEP), which exceeds
+      P_MAX once wait >= (P_MAX - p + 1) * AGE_STEP, and reaches P_MAX (winning FIFO ties against
+      newer jobs) at wait = (P_MAX - p) * AGE_STEP. Hence no ready job waits more than
+      (P_MAX - p) * AGE_STEP ticks. This bound depends on the wait clock being monotonic.
+
+      Worked example of the bound. With AGE_STEP=4, base priority p=1, and a stream whose maximum
+      base priority is P_MAX=2, the bound gives (2 - 1) * 4 = 4 ticks: a job of base priority 1
+      that arrived at tick 0 should reach effective priority 2 at tick 4 (floor(4/4)=1, so 1+1=2)
+      and win the FIFO tie against a same-effective newer job, running no later than tick 4.
+  - id: queue
+    type: code
+    label: scheduler/queue.ts (shipped)
+    content: |
+      // scheduler/queue.ts
+      export interface Job {
+        id: string;
+        basePriority: number;   // higher runs first
+        enqueuedAt: number;     // tick at which the job entered the ready queue
+      }
+
+      export class ReadyQueue {
+        private jobs: Job[] = [];
+
+        enqueue(job: Job, now: number): void {
+          job.enqueuedAt = now;
+          this.jobs.push(job);
+        }
+
+        // Called once per tick after arrivals are inserted, to keep ordering consistent.
+        reindex(now: number): void {
+          for (const j of this.jobs) j.enqueuedAt = now;   // align every wait clock to "now"
+          this.jobs.sort((a, b) => a.enqueuedAt - b.enqueuedAt);
+        }
+
+        effective(job: Job, now: number, ageStep: number): number {
+          return job.basePriority + Math.floor((now - job.enqueuedAt) / ageStep);
+        }
+
+        selectMax(now: number, ageStep: number): Job | null {
+          let best: Job | null = null;
+          for (const j of this.jobs) {
+            if (best === null) { best = j; continue; }
+            const je = this.effective(j, now, ageStep);
+            const be = this.effective(best, now, ageStep);
+            if (je > be || (je === be && j.enqueuedAt < best.enqueuedAt)) best = j;
+          }
+          return best;
+        }
+
+        remove(job: Job): void {
+          this.jobs = this.jobs.filter((j) => j.id !== job.id);
+        }
+
+        get size(): number { return this.jobs.length; }
+      }
+  - id: scheduler
+    type: code
+    label: scheduler/scheduler.ts (shipped)
+    content: |
+      // scheduler/scheduler.ts
+      import { ReadyQueue, type Job } from './queue';
+
+      export const AGE_STEP = 4;
+
+      // Advance one tick: insert arrivals, reindex, then run the highest-effective job.
+      export function step(now: number, arrivals: Job[], q: ReadyQueue): string | null {
+        for (const job of arrivals) q.enqueue(job, now);
+        q.reindex(now);                          // called unconditionally every tick
+        const chosen = q.selectMax(now, AGE_STEP);
+        if (chosen) q.remove(chosen);
+        return chosen ? chosen.id : null;
+      }
+  - id: fixtures
+    type: code
+    label: scheduler/scheduler.test.ts (green suite)
+    content: |
+      // scheduler/scheduler.test.ts  -- all passing
+      import { ReadyQueue, type Job } from './queue';
+      import { step } from './scheduler';
+
+      const job = (id: string, p: number): Job => ({ id, basePriority: p, enqueuedAt: 0 });
+
+      test('drains a static batch in base-priority order', () => {
+        const q = new ReadyQueue();
+        const order: (string | null)[] = [];
+        const arrivals = [job('a', 3), job('b', 2), job('c', 1)];   // all arrive at t=0
+        order.push(step(0, arrivals, q));   // 'a'
+        order.push(step(1, [], q));         // 'b'
+        order.push(step(2, [], q));         // 'c'
+        expect(order).toEqual(['a', 'b', 'c']);
+      });
+
+      test('a low-priority job in a batch still eventually runs', () => {
+        const q = new ReadyQueue();
+        step(0, [job('lo', 1), job('hi', 2)], q);   // 'hi' at t=0
+        const ran = step(1, [], q);                 // 'lo' runs, it is now alone
+        expect(ran).toBe('lo');
+      });
+
+      test('aging lets an older low job overtake within a small static set', () => {
+        const q = new ReadyQueue();
+        // three high jobs then one low, all at t=0; drains high-first then low, queue empties.
+        step(0, [job('h1', 2), job('h2', 2), job('lo', 1)], q); // h1
+        step(1, [], q);                                          // h2
+        const ran = step(2, [], q);                              // lo (now alone)
+        expect(ran).toBe('lo');
+      });
+
+      // NOTE: no test sustains arrivals across ticks. Every case above drains to an empty queue,
+      // so a carried-over job never competes with a fresh arrival for more than the tick it runs.
+      // The aging path is never actually exercised under sustained contention, and reindex is only
+      // ever called on queues that are about to empty, where resetting enqueuedAt is harmless.
+  - id: observed-run
+    type: table
+    label: Recorded production run under a saturating stream (AGE_STEP = 4)
+    content: |
+      Input stream: at t=0 two jobs arrive, L (base 1) and H0 (base 2). At every tick t >= 1 one
+      new job Ht (base 2) arrives. P_MAX = 2 throughout. Columns show L's enqueuedAt AFTER reindex,
+      and the effective priorities used for selection.
+
+      tick | arrived | ran | L.enqueuedAt | eff(L) | eff(Ht) | queue after
+      0    | L, H0   | H0  | 0            | 1      | 2       | {L}
+      1    | H1      | H1  | 1            | 1      | 2       | {L}
+      2    | H2      | H2  | 2            | 1      | 2       | {L}
+      3    | H3      | H3  | 3            | 1      | 2       | {L}
+      4    | H4      | H4  | 4            | 1      | 2       | {L}
+      5    | H5      | H5  | 5            | 1      | 2       | {L}
+      6    | H6      | H6  | 6            | 1      | 2       | {L}
+      7    | H7      | H7  | 7            | 1      | 2       | {L}
+      8    | H8      | H8  | 8            | 1      | 2       | {L}
+      9    | H9      | H9  | 9            | 1      | 2       | {L}
+      10   | H10     | H10 | 10           | 1      | 2       | {L}
+
+      L is still queued after tick 10 with effective priority 1. It has run zero times. Note that
+      L.enqueuedAt tracks the tick number exactly, never the constant 0 it was enqueued with; its
+      recorded wait is 0 every tick.
+  - id: scheduler-debug
+    type: log
+    label: Shipped scheduler debug log (first ticks of the production run)
+    content: |
+      Verbose per-tick output from the shipped scheduler on the observed-run stream. "reindex:"
+      lines print each job's enqueuedAt as old->new.
+
+      [t=0] arrivals: L(base=1), H0(base=2)
+      [t=0] reindex: L 0->0, H0 0->0
+      [t=0] effective: L=1, H0=2
+      [t=0] select -> H0 ; queue={L}
+      [t=1] arrivals: H1(base=2)
+      [t=1] reindex: L 0->1, H1 1->1        # L wait clock moved from 0 to 1
+      [t=1] effective: L=1, H1=2
+      [t=1] select -> H1 ; queue={L}
+      [t=2] arrivals: H2(base=2)
+      [t=2] reindex: L 1->2, H2 2->2        # L wait clock moved from 1 to 2
+      [t=2] effective: L=1, H2=2
+      [t=2] select -> H2 ; queue={L}
+      [t=3] arrivals: H3(base=2)
+      [t=3] reindex: L 2->3, H3 3->3        # L wait clock moved from 2 to 3
+      [t=3] effective: L=1, H3=2
+      [t=3] select -> H3 ; queue={L}
+      [t=4] arrivals: H4(base=2)
+      [t=4] reindex: L 3->4, H4 4->4        # L wait clock moved from 3 to 4
+      [t=4] effective: L=1, H4=2            # under monotonic wait, eff(L) would be 2 here
+      [t=4] select -> H4 ; queue={L}
+  - id: claim
+    type: note
+    label: Claimed invariant and on-call theories
+    content: |
+      Claimed invariant (starvation-freedom with bound): under FairShare Scheduler v2, every ready
+      job eventually runs; specifically a ready job with base priority p is selected within
+      (P_MAX - p) * AGE_STEP ticks of continuous waiting, where P_MAX is the maximum base priority
+      present. The team asserts the shipped code implements this because effective() adds the aging
+      term.
+
+      Two on-call theories were proposed and are NOT necessarily correct:
+        T1: "AGE_STEP = 4 is too coarse; the aging term grows too slowly. Lower AGE_STEP to 1 and
+            the low-priority job will catch up." (Consider: with AGE_STEP=1, what is floor(0/1)?)
+        T2: "The scheduler is really just strict-priority FIFO and the aging code is dead. The fix
+            is to add a force-run counter that runs any job passed over K times." A patch built on
+            T2 is attached as proposed-patch.
+
+      A third suggestion, quickly dismissed, was that the counterexample requires forbidding new
+      arrivals; but the spec explicitly permits a new job every tick, so any valid counterexample
+      may use a saturating stream.
+
+      Do not assume any theory is right. Decide the invariant on the semantics, and only then judge
+      the theories and the patch.
+  - id: proposed-patch
+    type: diff
+    label: Proposed force-run patch (built on theory T2)
+    content: |
+      Adds a skip counter and force-runs any job skipped FORCE_AFTER times. FORCE_AFTER = 3.
+      scheduler.step() is also updated to increment skips on every ready job that was not selected
+      this tick (one increment per tick per unselected job).
+
+       export interface Job {
+         id: string;
+         basePriority: number;
+         enqueuedAt: number;
+      +  skips: number;          // number of ticks this job has been passed over
+       }
+
+       enqueue(job: Job, now: number): void {
+         job.enqueuedAt = now;
+      +  job.skips = 0;
+         this.jobs.push(job);
+       }
+
+       reindex(now: number): void {
+         for (const j of this.jobs) j.enqueuedAt = now;
+      +  for (const j of this.jobs) j.skips = 0;      // keep counters aligned with the wait clock
+         this.jobs.sort((a, b) => a.enqueuedAt - b.enqueuedAt);
+       }
+
+       selectMax(now: number, ageStep: number): Job | null {
+      +  const forced = this.jobs.find((j) => j.skips >= 3);   // FORCE_AFTER = 3
+      +  if (forced) return forced;
+         let best: Job | null = null;
+         // ... unchanged effective-priority selection ...
+       }
+
+      Author's note: "Any job skipped three times gets force-run. Starvation is now impossible. I
+      left reindex() as-is and just aligned the new counter with it for consistency."
+tags: [scheduling, fairness, starvation, aging, formal-reasoning, counterexample]