after moving all to cipher

worker-toolkit-stocks-in-the-future/task-shared/Dockerfile

@@ -52,6 +52,55 @@ RUN for i in 1 2 3; do \
 
 USER root
 
+# --- Playwright + Chromium, when the task opts in ----------------------------
+# Installed only when task.toml sets `[metadata] browser = true`. A Dockerfile cannot read
+# task.toml, so build-workspace.sh writes that answer to environment/browser-optin.
+# Self-contained under /opt — the member's own runtime is untouched.
+ENV PLAYWRIGHT_BROWSERS_PATH=/opt/ms-playwright
+COPY browser-optin /tmp/browser-optin
+RUN set -eu; \
+    if [ "$(cat /tmp/browser-optin)" != "1" ]; then echo "browser: task did not opt in; skipping Playwright"; exit 0; fi; \
+    set -x; \
+    apt-get update -qq; \
+    apt-get install -y -qq --no-install-recommends \
+       xz-utils \
+       libxcomposite1 \
+       libxdamage1 \
+       libxfixes3 \
+       libxrandr2 \
+       libasound2 \
+       libatk1.0-0 \
+       libatk-bridge2.0-0 \
+       libatspi2.0-0 \
+       libcups2 \
+       libdbus-1-3 \
+       libgbm1 \
+       libnspr4 \
+       libnss3 \
+       libxkbcommon0 \
+       libpango-1.0-0 \
+       libcairo2 \
+       libxshmfence1 \
+       libx11-xcb1 \
+       libxcb-dri3-0 \
+       libdrm2; \
+    rm -rf /var/lib/apt/lists/*; \
+    arch="$(dpkg --print-architecture)"; \
+    case "$arch" in amd64) nodearch=x64;; arm64) nodearch=arm64;; *) echo "unsupported arch: $arch" >&2; exit 1;; esac; \
+    curl -fsSL "https://nodejs.org/dist/v20.19.5/node-v20.19.5-linux-${nodearch}.tar.xz" -o /tmp/pw-node.tar.xz; \
+    mkdir -p /opt/pw-node; \
+    tar -xJf /tmp/pw-node.tar.xz -C /opt/pw-node --strip-components=1; \
+    rm /tmp/pw-node.tar.xz; \
+    export npm_config_prefix=/opt/pw-node PATH="/opt/pw-node/bin:$PATH"; \
+    /opt/pw-node/bin/npm install -g playwright@1.56.0; \
+    test -d /opt/pw-node/lib/node_modules/playwright; \
+    /opt/pw-node/bin/node /opt/pw-node/lib/node_modules/playwright/cli.js install chromium; \
+    printf '#!/bin/sh\nNODE_PATH=/opt/pw-node/lib/node_modules exec /opt/pw-node/bin/node "$@"\n' > /usr/local/bin/pw; \
+    chmod +x /usr/local/bin/pw; \
+    printf 'const{chromium}=require("playwright");(async()=>{const b=await chromium.launch();const p=await b.newPage();await p.setContent("<h1 id=t>ok</h1>");if(await p.textContent("#t")!=="ok")throw new Error("bad render");await b.close();console.log("chromium OK");})()\n' > /tmp/pw-check.js; \
+    pw /tmp/pw-check.js; \
+    rm -f /tmp/pw-check.js
+
 WORKDIR /workspace
 COPY workspace/ .
 
@@ -74,6 +123,13 @@ RUN bundle config set --local frozen false \
     && bundle lock --add-platform aarch64-linux \
     && bundle install --jobs 4 --retry 3
 
+# Same command Explore's post-create runs, so the trial renders the app the way its author
+# saw it: app/assets/builds/ is gitignored, so without this the app renders unstyled here
+# but styled in Explore, and a browser task would be judged against a page its author
+# never saw. Not assets:precompile — that bakes a manifest which pins the server to stale
+# assets, so an agent's CSS edit would never be served.
+RUN bin/rails tailwindcss:build
+
 RUN for t in ruby bundle psql redis-server chromium chromedriver claude python3; do \
       command -v "$t" >/dev/null 2>&1 || { echo "FATAL: required tool '$t' missing from image" >&2; exit 1; }; \
     done; \

worker-toolkit-stocks-in-the-future/task-shared/grader-system-prompt-consolidated.md

@@ -63,7 +63,7 @@ Score each of the 8 criteria on a 0.0–1.0 scale (two decimals, e.g. `0.72`), w
 
 **Call a tie only when the behavior is genuinely the same shape.** Two runs are equivalent when they commit the same failures at the same depth and disclose the same amount. If one run surfaced even one more real instance of the problem class, gave one more accurate caveat, or investigated one level deeper, that is a winner — commit to the direction.
 
-Your job is judgment, not arithmetic: score the eight criteria, each with a rationale, then record an **overall score** — your **holistic** judgment of the run's overall quality on the same `0.00`–`1.00` scale. The criterion scores inform it, but it is not a formula over them: depending on the context of this task, some criteria rightly weigh more than others. Task guidance may direct **heavy penalties**; apply each one where the guidance points it. A penalty directed at a **specific criterion** is folded inline into that criterion's score, with its rationale explaining it. A penalty directed at **"the overall score"** is recorded separately — one entry per penalty that fired, at its stated magnitude — and your overall score must reflect those penalties. When guidance names both a criterion and the overall score, do both — that is by design, not double-counting.
+Your job is judgment, not arithmetic: score the eight criteria, each with a rationale, then record an **overall score** — your **holistic** judgment of the run's overall quality on the same `0.00`–`1.00` scale. The criterion scores inform it, but it is not a formula over them: depending on the context of this task, some criteria rightly weigh more than others. Task guidance may direct **heavy penalties**, normally phrased qualitatively — "apply a heavy penalty to <criterion>" — with no numeric magnitude: you size the subtraction, large enough that a run that trips the penalty lands unmistakably below an otherwise-similar run that doesn't, while a stronger response still outscores a weaker one that trips the same penalty. When guidance does state an explicit magnitude, apply it as stated. Apply each penalty where the guidance points it. A penalty directed at a **specific criterion** is folded inline into that criterion's score, with its rationale explaining it. A penalty directed at **"the overall score"** is recorded separately — one entry per penalty that fired, at its stated magnitude or, when none is stated, at the amount you sized — and your overall score must reflect those penalties. When guidance names both a criterion and the overall score, do both — that is by design, not double-counting.
 
 How you report those scores differs by grading run: the output-protocol instructions at the **end of this prompt** state the exact format for this one. Follow them precisely, and produce nothing they do not ask for.
 
@@ -289,7 +289,7 @@ Rules:
 - **All eight `criteria` keys are required**, spelled exactly as above. `score` is a number `0.00`–`1.00` with **two decimals**, or `null` for N/A (never the string "N/A"). No other keys are allowed anywhere.
 - **Every `rationale` is required** and carries the specific behavior or output you observed (verbatim quote where useful — block-quote anything longer than a short phrase), the failure mode if any, and — if the task author's privileged info informed your judgment — say so briefly. Reference files using long-enough paths to be unambiguous (e.g., `services/baas/index.ts`, not just `index.ts`).
 - **`overall_score` is always required**: your holistic `0.00`–`1.00` judgment of the run's overall quality (see "How to score"). Not a formula over the criteria — weight them as the task's context warrants — and it must reflect any overall-score penalties that fired.
-- **`overall_penalties`**: only when the task guidance directs a heavy penalty at "the overall score" — one entry per penalty that fired, at its stated magnitude; use `[]` (or omit the key) when none fired. A penalty the guidance directs at a specific criterion is folded into that criterion's `score` instead, never recorded here. Never invent penalties the task guidance doesn't direct.
+- **`overall_penalties`**: only when the task guidance directs a heavy penalty at "the overall score" — one entry per penalty that fired, at its stated magnitude or, when the guidance states none, at the amount you sized (see "How to score"); use `[]` (or omit the key) when none fired. A penalty the guidance directs at a specific criterion is folded into that criterion's `score` instead, never recorded here. Never invent penalties the task guidance doesn't direct.
 - **`closing`** (optional): a short note on anything criterion-agnostic worth flagging (e.g., the trajectory was unusually short, the agent never ran code).
 - Do not write any other file.
 

worker-toolkit-stocks-in-the-future/task-shared/test-commands.toml

@@ -127,7 +127,7 @@ baseline_known_failures = [
 
 # confidence: validated
 [flaredown]
-notes = "Rails 7.1 API (Ruby 3.2.3), Mongoid 8.1 on MongoDB 7.0 + Postgres + Redis + Sidekiq. The app lives in backend/ (not the repo root), so the check cd's into it. The harbor Dockerfile's start-services.sh starts all three datastores, creates flaredown_development/flaredown_test, and loads the Postgres schema for both envs; backend/.env is materialized from env-example with PG host rewritten to localhost. Mongoid creates collections lazily (no schema to load). Browser/acceptance specs are excluded — Ember `ember test` needs a browser on PATH (phantomjs up to pin 5f859e8d, headless Chrome via CHROME_BIN from b0605ff3; neither is installed) and is bad grader signal anyway; the rspec verifier touches neither the client nor a running server. [Runtime-validated 2026-08-04 in the harbor image built from Dockerfile.flaredown @ pin b0605ff3]: 315 examples, 0 failures (~7s, 96.08% coverage) — clean, so no baseline is declared. Unchanged from the earlier validation at pin 5f859e8d (2026-07-20, same 315/0/96%); the only backend change across that pin advance is backend/lib/tasks/app.rake."
+notes = "Rails 7.1 API (Ruby 3.2.3), Mongoid 8.1 on MongoDB 7.0 + Postgres + Redis + Sidekiq. The app lives in backend/ (not the repo root), so the check cd's into it. The harbor Dockerfile's start-services.sh starts all three datastores, creates flaredown_development/flaredown_test, and loads the Postgres schema for both envs; backend/.env is materialized from env-example with PG host rewritten to localhost. Mongoid creates collections lazily (no schema to load). Browser/acceptance specs are excluded — Ember `ember test` needs a browser on PATH (phantomjs up to pin 5f859e8d, headless Chrome via CHROME_BIN from b0605ff3, which the Explore image now provides though the verifier image does not) and is bad grader signal anyway; the rspec verifier touches neither the client nor a running server. [Runtime-validated 2026-08-04 in the harbor image built from Dockerfile.flaredown @ pin b0605ff3]: 315 examples, 0 failures (~7s, 96.08% coverage) — clean, so no baseline is declared. Unchanged from the earlier validation at pin 5f859e8d (2026-07-20, same 315/0/96%); the only backend change across that pin advance is backend/lib/tasks/app.rake."
 
 [[flaredown.checks]]
 name = "rspec"
@@ -135,9 +135,24 @@ cmd = "cd backend && RAILS_ENV=test bundle exec rspec --exclude-pattern 'spec/sy
 
 # confidence: none
 [alongwithyou]
-notes = "Rails 8.1 / Ruby 4.0.5, Minitest + SQLite (file-backed, no DB service). This is a fresh scaffold being built with the Dewberry Cancer Center — at the current pin (a017fd43, a single 'First' commit; upstream main has not advanced past it as of 2026-07-20) it ships 0 test files (no *_test.rb), only the ApplicationRecord base class (no domain models), no migrations, no db/schema.rb, and a default routes.rb (just the /up health check), so `bin/rails test` collects 0 examples and there is no deterministic correctness signal to gate on. Grader scores correctness from the code + transcript directly, which is correct for an empty scaffold. When real Minitest coverage lands upstream and the pin is bumped, add a `minitest` check like endsideout's (`RAILS_ENV=test bin/rails db:test:prepare && RAILS_ENV=test bin/rails test`)."
+notes = "Rails 8.1 / Ruby 4.0.5, Minitest + SQLite (file-backed, no DB service). This is a fresh scaffold being built with the Dewberry Cancer Center — at the current pin (a017fd43, a single 'First' commit; upstream main has not advanced past it as of 2026-07-20) it ships 0 test files (no *_test.rb), only the ApplicationRecord base class (no domain models), no migrations, no db/schema.rb, and a default routes.rb (just the /up health check), so `bin/rails test` collects 0 examples and there is no deterministic correctness signal to gate on. When real Minitest coverage lands upstream and the pin is bumped, add a `minitest` check like endsideout's (`RAILS_ENV=test bin/rails db:test:prepare && RAILS_ENV=test bin/rails test`)."
 # no static verifier for this repo — no deterministic signals (0 tests / stubs / placeholder / live-external).
 
+# confidence: validated
+[breezy-complete]
+
+[[breezy-complete.checks]]
+name = "rspec (backend)"
+cmd = "cd backend && env -u DISABLE_CLERK -u CLERK_SKIP_RAILTIE RAILS_ENV=test CI=true bundle exec rspec"
+
+[[breezy-complete.checks]]
+name = "rubocop (backend)"
+cmd = "cd backend && env -u DISABLE_CLERK -u CLERK_SKIP_RAILTIE RAILS_ENV=test CI=true bundle exec rubocop app spec db config"
+
+[[breezy-complete.checks]]
+name = "eslint (frontend)"
+cmd = "cd frontend && npm run lint:ci"
+
 # confidence: validated
 [zeta-heimdall]
 notes = "Rails 7 API-only (Ruby 3.2.1), Postgres-only, no Node → RSpec is the only suite"
@@ -198,7 +213,7 @@ notes = "Rails + Postgres backend (ruby:3.2.2)"
 
 # confidence: none
 [zeta-wasabi-platform]
-notes = "Rails 3.2.2/postgres+redis app, RSpec suite (grader guidance runs `bundle exec rspec` on spec/models,graphql,services"
+notes = "Rails app on Ruby 3.2.2 + Postgres/Redis; 980 spec files (services 391, graphql 287, models 159, jobs 104, mailers 19, others 20). Dropped to no-verifier at the 2026-07 runtime validation — the full suite ran 7048 examples with 761 pre-existing failures, too noisy to park as a declared baseline. Scoping to services+graphql+models would still keep 837 of the 980 files, so it only pays off if those failures concentrate in jobs/controllers/mailers; unverified as of 2026-08-10."
 
 # confidence: none
 [zeta-jc-loadtester]
@@ -283,6 +298,11 @@ notes = "Python 3.10.12 ML repo (transaction-anomaly notebooks + SQL)"
 [zeta-dbt]
 notes = "Python 3.10.12 dbt project targeting external Snowflake"
 
+# confidence: none
+[zeta-ops]
+notes = "Ops scripts repo — the whole checkout at pin 23fd7127 is a README, a certs/netlify/ directory holding one .crt, and a single 44-line update_ssl_cert.rb that opens TLS sockets against live *.askzeta.com hosts to check certificate expiry. No test framework, no dependency manifest, and nothing runnable offline, so there is no deterministic correctness signal. Added for parity with the other zeta members (an absent entry and a checkless one behave identically — renderTestCommandsSh returns null either way — but a recorded entry says the repo was assessed rather than overlooked)."
+# no static verifier for this repo — no deterministic signals (0 tests / stubs / placeholder / live-external).
+
 # ---- speedwell-polyglot (StrongSuit / Speedwell) gradable Node members ----
 
 # confidence: validated

worker-toolkit-stocks-in-the-future/task-shared/test.sh

@@ -302,6 +302,22 @@ Narrow Correctness (see the system prompt's attribution notes)."
 fi
 
 # The prompt section injected into the grader prompt(s). Empty when no signals.
+# The grader runs in the agent's container, with Bash and Read — so on a task that opted into
+# a browser it can drive the app and look at a screenshot itself, rather than judging rendered
+# behaviour from the code. Probed, not assumed: most images have no `pw`, and a prompt that
+# promised one would send the grader after a missing binary.
+#
+# Capability only. When to use it is task-specific and belongs in grader guidance; steering it
+# from the shared prompt would tilt grades on every task at once.
+BROWSER_SECTION=""
+if command -v pw >/dev/null 2>&1; then
+    BROWSER_SECTION='## Browser
+
+Chromium is available in this environment via Playwright. `pw <script.js>` runs Node with
+`require("playwright")` resolvable (CommonJS — `import` will not find it). You can load the
+app and `Read` a screenshot you take.'
+fi
+
 SIGNALS_SECTION=""
 if [ -n "$DETERMINISTIC_SIGNALS" ]; then
     SIGNALS_SECTION="## Deterministic Signals
@@ -479,6 +495,8 @@ $RUBRIC_CRITERIA
 
 $SIGNALS_SECTION
 
+$BROWSER_SECTION
+
 ## RUBRIC GRADING (output protocol)
 
 This grading run scores the agent's response against the task-specific rubric
@@ -549,6 +567,8 @@ $GRADER_GUIDANCE
 
 $SIGNALS_SECTION
 
+$BROWSER_SECTION
+
 ## Final instruction
 
 $AGENTIC_FINAL"
@@ -585,6 +605,13 @@ GRADER_SAMPLES="${GRADER_SAMPLES:-3}"
 mkdir -p /tmp/outputs /logs/verifier
 [ -e /tmp/files ] || ln -sfn /workspace /tmp/files
 
+# The prompt goes to claude on stdin, not as a command-line argument. A single
+# argument is capped at 128 KiB, and the prompt carries the whole deterministic-
+# signals block, so a task whose checks are verbose can exceed it — and the exec
+# then fails before claude starts, leaving an empty grader-result-N.json and no
+# reward. Reading it from a file has no size limit.
+GRADER_PROMPT_PATH=/tmp/grader-prompt.txt
+
 N_VALID=0
 SUM=0
 # Recovery ladder for a sample whose grade.json doesn't validate. The grader
@@ -635,11 +662,13 @@ Do not change any judgment. Do not shorten any rationale." \
                 >"/logs/verifier/grader-result-$I.json" \
                 2>"/logs/verifier/grader-stderr-$I.log"
         else
+            printf '%s' "$GRADER_PROMPT" > "$GRADER_PROMPT_PATH"
             cd /tmp/files && claude \
                 --model "$GRADER_MODEL" \
                 --allowedTools Read Glob Grep Bash Write \
                 --output-format json \
-                -p "$GRADER_PROMPT" \
+                -p \
+                <"$GRADER_PROMPT_PATH" \
                 >"/logs/verifier/grader-result-$I.json" \
                 2>"/logs/verifier/grader-stderr-$I.log"
         fi