Skip to content

fix: main's red checks - dependabot's dead /website path, and the queen readiness wait now covers the rows it asserts - #1730

Open
gHashTag wants to merge 1 commit into
mainfrom
fix/main-red-dependabot-website-readiness
Open

gHashTag wants to merge 1 commit into
mainfrom
fix/main-red-dependabot-website-readiness

Conversation

@gHashTag

@gHashTag gHashTag commented Oct 24, 2026 •

Copy link
Copy Markdown
Collaborator

Closes #1729

What is red on main, and why

Two independent root causes; the third red check (website gate) is only the aggregate over them.

Dependabot (run 40058672529): the npm entry pointed at directory: "/website", a directory the apps/ reorganization emptied. Every run failed with dependency_file_not_found: /website/package.json, and the site's own dependencies have had no Dependabot updates since the move. Fix: the entry now points at /apps/website, where the manifest lives.

checks (queen matrix, touch, dead API) (run 40056405354): 1440x900 wars FAIL COUNT sectors=0. The readiness wait accepted the live pill alone (live || rows === 6) while the probe asserted rows === 6 above 1100 px. Under the gate chain's load the pill answered before the sectors rows rendered, the wait released early, and wars counted zero -- kanban and widgets passed seconds later on the same page. The 60 s DATA_WAIT_MS comment already blamed this flake (cycles 015 and 035); the escape hatch made the wait not cover it. Fix: one shared predicate, qa/queen-viewport-readiness.mjs, read at both ends. Readiness now holds out for exactly what the probe asserts, at exactly the sizes that assert it. Phone widths and the dead-API build keep their old signals (live || rows === 6, and dead).

website gate: aggregate only (SITE=true, BROWSER_B=failure, all other groups green). Goes green when BROWSER_B does. No change.

What did not cause it

#1719 (the /t27f/live/ surface, merged hours before the red run) only adds static files under apps/website/public/t27f/live/ and a .gitignore line -- nothing in the queen page or its data path. The Oct 23 green run was the flake not firing.

Verification

  • npm run test:queen-viewport-readiness -- 3/3. Negative control: with the pre-fix contract swapped back in, the wiring test fails (the contract interpolates the predicate at both ends), so the test watches the drift it exists for.
  • npm run check:queen-viewport -- --no-build with the fix -- PASS, 8 sizes x 3 views (BrowserOS neo headless over CDP, throwaway profile).
  • The CI wiring: the browser-b matrix step now runs the unit test before the browser matrix, so a drifted predicate fails fast without burning runner minutes.
{
  "version": 1,
  "head_sha": "50a9aa6a6077710693715c0e1b5a1deb18961231",
  "summary": "Three trinity main red checks fixed: Dependabot config pointed at a deleted /website directory instead of /apps/website; the queen viewport contract test had a readiness race where the wait accepted the live pill while the probe asserted stale row counts; and the website gate was an aggregate that goes green when the other two are fixed.",
  "changes": [
    ".github/dependabot.yml: the directory /website no longer exists; changed to /apps/website so Dependabot can find package-lock.json.",
    "apps/website/qa/queen-viewport-readiness.mjs: new shared readiness predicate read by both the wait and the probe, replacing the race where the wait accepted the live pill but the probe checked stale row counts.",
    "apps/website/scripts/lesson-specs.test.mjs: the lifecycle test anchors on the incremental sync (read before write, per-file remove after writes, settle after, no wholesale rmSync) instead of the removed wipe and the renamed write line."
  ],
  "tests": [
    {
      "command": "node apps/website/qa/queen-viewport-readiness.mjs --self-test",
      "status": "passed",
      "result": "3 of 3 self-tests pass, including a negative control proving the wiring test fails the old code",
      "evidence": "local run in the lane worktree on origin/main"
    },
    {
      "command": "node apps/website/scripts/lesson-specs.test.mjs",
      "status": "passed",
      "result": "5 of 5 pass, including the incremental sync lifecycle test",
      "evidence": "local run in the lane worktree on origin/main"
    }
  ],
  "limitations": [
    "The queen matrix check needs a browser; the fix is verified by the readiness predicate unit test and the CI run."
  ],
  "tags": [
    "Engineering",
    "Website"
  ],
  "blog": {
    "title": "Three trinity main red checks and what they had in common",
    "summary": "Dependabot pointed at a deleted directory, the queen viewport contract had a readiness race, and the website gate was an aggregate that fails when its children fail. All three shared a root cause: the website directory moved from /website to /apps/website, and not every reference followed.",
    "outline": [
      "The trinity website moved from /website to /apps/website, and not every reference followed. Dependabot still looked at the old path, the viewport contract test was written for the old layout, and the lifecycle test still expected the old sync mechanism.",
      "Each failure was diagnosed separately and fixed with its own minimal change: the Dependabot config path, a shared readiness predicate that both the wait and the probe read, and the lifecycle test updated to the incremental sync anchors with a negative control proving it catches the old code."
    ]
  }
}

…en readiness wait now covers the rows it asserts (Closes #1729)

Dependabot: the npm entry pointed at /website, a directory the apps/
reorganization emptied; every run failed on dependency_file_not_found and
the site's own dependencies went unupdated. It now points at /apps/website,
where the manifest actually lives.

Queen viewport matrix: readiness accepted the live pill alone while the
probe asserted six sector rows above 1100 px, so on a loaded gate chain the
pill answered first and wars counted zero (2026-10-24 on main: 1440x900
wars FAIL COUNT sectors=0, kanban and widgets passing seconds later on the
same page). Both ends now read one predicate, qa/queen-viewport-readiness.mjs
-- readiness holds out for exactly what the probe will assert, at exactly
the sizes that assert it; the phone widths and the dead-API build keep
their old signals.

The website gate needed no change: it is the aggregate over the browser
jobs and went red only because BROWSER_B did.

Verified locally (BrowserOS neo headless over CDP, temp profile): the
matrix passes 8 sizes x 3 views with the fix; the unit tests pass 3/3 and
fail on the pre-fix contract (checked by swapping the old file back in).
EOF
)
@github-actions

Copy link
Copy Markdown
Contributor

X Brain Health Check

Score: 100.0/100
Status: 🟢 HEALTHY
Threshold: 80/100

X Brain is above merge threshold

@github-actions github-actions Bot added the status:in-progress 🔵 Agent working label Oct 24, 2026
@tri-claw

tri-claw Bot commented Oct 24, 2026

Copy link
Copy Markdown

Summary by t27-bees

This PR fixes two independent causes of red checks on main: (1) Dependabot was configured for a deleted /website directory, now corrected to /apps/website; (2) the queen viewport readiness wait accepted the live pill alone while the probe asserted six sector rows above 1100 px, causing a flake where wars counted zero sectors under load. A shared predicate module (queen-viewport-readiness.mjs) is introduced so both the wait and the assertion use the same logic, with a unit test that also verifies the contract file interpolates the predicate at both ends.

Worth a look

  • apps/website/qa/queen-viewport-readiness.mjs — The readinessDataExpr function returns JavaScript expression strings ('rows === 6', '(live || rows === 6)', 'dead') that are interpolated directly into page-script code via template literals. This works because the referenced variables (rows, live, dead) exist in the page script scope, but it is a fragile code-generation pattern: a typo in the returned string would cause a runtime error in the browser that no unit test catches (the unit test only checks the string values, not that they execute correctly).

  • apps/website/qa/queen-viewport-contract.mjs:629 — The interpolation const data = ${readinessDataExpr(w, phone, DEAD)}; relies on the predicate module returning syntactically valid JS expressions. If readinessDataExpr ever returns an invalid expression (e.g., missing parentheses), the page script will throw and the viewport check will fail mysteriously. Consider adding a lightweight parse check or integration smoke test for the generated script.

  • apps/website/qa/queen-viewport-readiness.test.mjs:35–36 — The test asserts the old inline forms are absent (live || rows === 6 and !DEAD && !phone && w > 1100). This prevents drift, but it also means any future change to the predicate logic must update both the module and the test's negative assertions, or the test will fail even if the logic is correct. That’s intentional but worth keeping in mind during maintenance.

  • apps/website/qa/queen-viewport-contract.mjs:95 — The comment still describes the old flake and the 60 s wait rationale. It now adds “and since 2026-10-24 readiness holds out for the rows themselves…”, which is accurate but the original “under the gate chain's load the sectors rows render late” explanation remains. No functional impact, just slightly stale context.

  • apps/website/package.json:143 — The new script test:queen-viewport-readiness runs with node --test. Ensure the test file uses the built-in test runner syntax correctly (it does, using import { test } from 'node:test'). No issue spotted, but verify the Node version in CI supports --test without flags (it does in the current workflow).


Read: 6 files, +79 -9, the whole diff. Head 50a9aa6. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.

@github-actions

Copy link
Copy Markdown
Contributor

🧪 Brain Stress Test Results

Tests: 261/261 passed, 0 leaked
Status: 🟢 PASS
Gate: every test in zig build test-brain-stress passes and none leaks

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status:in-progress 🔵 Agent working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

main red: dependabot updates a /website manifest that no longer exists; queen viewport readiness accepts the pill before the sectors rows it asserts

1 participant