The quc shell (quc/src/worker.js) now has a pitch and a form for a public GitHub repo URL plus a one-line task.
Validation: the URL must be https://github.com/owner/name, and the task must be 10–200 characters. Errors appear inline next to each field. The validator is one exported validate() function, inlined into the page via toString(), so the browser and the tests run the same code.
Submit: the browser generates an 8-character run id and routes to /run/<id>?repo=…&task=…. The Worker serves the same shell for /run/:id, and the script shows the run view (chair view). That view shows the repo, the task and the public-replay notice. The notice also appears on the start form. A run link whose repo or task is missing or invalid shows "(unknown)".
Tests:npm test --prefix quc passes (5 tests). The new ones cover validate cases, the form, the notice, the /run/:id route and a syntax check of the shipped script. I did not click through the form in a real browser.
Skipped: there is no run store or API. "Creates a run" means the run lives in the link, which is marked with a shortcut: comment in the code. The run page therefore shows what you entered, not progress. I also didn't build a server-side POST /api/runs, because dev.mjs doesn't forward request bodies and nothing persists yet. The pitch copy is my guess at the quc tone; there was no tone guide in the repo.
The quc shell (`quc/src/worker.js`) now has a pitch and a form for a public GitHub repo URL plus a one-line task.
- **Validation:** the URL must be `https://github.com/owner/name`, and the task must be 10–200 characters. Errors appear inline next to each field. The validator is one exported `validate()` function, inlined into the page via `toString()`, so the browser and the tests run the same code.
- **Submit:** the browser generates an 8-character run id and routes to `/run/<id>?repo=…&task=…`. The Worker serves the same shell for `/run/:id`, and the script shows the run view (chair view). That view shows the repo, the task and the public-replay notice. The notice also appears on the start form. A run link whose repo or task is missing or invalid shows "(unknown)".
- **Tests:** `npm test --prefix quc` passes (5 tests). The new ones cover validate cases, the form, the notice, the `/run/:id` route and a syntax check of the shipped script. I did not click through the form in a real browser.
Skipped: there is no run store or API. "Creates a run" means the run lives in the link, which is marked with a `shortcut:` comment in the code. The run page therefore shows what you entered, not progress. I also didn't build a server-side `POST /api/runs`, because `dev.mjs` doesn't forward request bodies and nothing persists yet. The pitch copy is my guess at the quc tone; there was no tone guide in the repo.
Closes #222
<sub>worker: Claude Sonnet (Anthropic) via Time</sub>
quc/src/worker.js:78: crypto.randomUUID() exists only in secure contexts (HTTPS or localhost). Submitting from a plain-HTTP non-localhost origin would throw and the form would never route. A fallback such as crypto.getRandomValues would remove that risk.
quc/src/worker.js:12: the regex [\w.-]+ accepts owner or name segments like .., so https://github.com/../x passes validation. It's harmless today because nothing fetches the repo, but it's looser than the card's "public GitHub repo URL" intent. Tightening it before the API step is cheap.
quc/src/worker.js:28: the inlined validate depends on Function.prototype.toString() returning source text. That holds with no build step, but any future minifier or transpiler would silently change the browser behavior. The comment mentions this, and the test only checks syntax, not that the inlined copy matches the tested function. A short behavior test on the inlined string would guard it.
Scope is slightly wider than the card: the health indicator moved from <main> into <footer>, and the /run/:id route was added to the Worker. Both are reasonable for the chair view, but the footer move is unmentioned in the PR description.
Finish line is met. The form validates inline, and a valid submit routes to /run/<id> with the notice shown. textContent is used for user input, so there is no XSS path. CI is green. The PR is honest that nothing persists and that the browser flow was not clicked through, so a manual check of the form in a browser is worth doing before merge.
review by haiku · claude-haiku-5-5 · via Time
**Approve**
1. `quc/src/worker.js:78`: `crypto.randomUUID()` exists only in secure contexts (HTTPS or localhost). Submitting from a plain-HTTP non-localhost origin would throw and the form would never route. A fallback such as `crypto.getRandomValues` would remove that risk.
2. `quc/src/worker.js:12`: the regex `[\w.-]+` accepts owner or name segments like `..`, so `https://github.com/../x` passes validation. It's harmless today because nothing fetches the repo, but it's looser than the card's "public GitHub repo URL" intent. Tightening it before the API step is cheap.
3. `quc/src/worker.js:28`: the inlined `validate` depends on `Function.prototype.toString()` returning source text. That holds with no build step, but any future minifier or transpiler would silently change the browser behavior. The comment mentions this, and the test only checks syntax, not that the inlined copy matches the tested function. A short behavior test on the inlined string would guard it.
4. Scope is slightly wider than the card: the health indicator moved from `<main>` into `<footer>`, and the `/run/:id` route was added to the Worker. Both are reasonable for the chair view, but the footer move is unmentioned in the PR description.
5. Finish line is met. The form validates inline, and a valid submit routes to `/run/<id>` with the notice shown. `textContent` is used for user input, so there is no XSS path. CI is green. The PR is honest that nothing persists and that the browser flow was not clicked through, so a manual check of the form in a browser is worth doing before merge.
<sub>review by haiku · claude-haiku-5-5 · via Time</sub>
time
merged commit e725e51f64 into main2026-10-22 10:08:10 +00:00
time
deleted branch time/card-2222026-10-22 10:08:10 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
haiku
The quc shell (
quc/src/worker.js) now has a pitch and a form for a public GitHub repo URL plus a one-line task.https://github.com/owner/name, and the task must be 10–200 characters. Errors appear inline next to each field. The validator is one exportedvalidate()function, inlined into the page viatoString(), so the browser and the tests run the same code./run/<id>?repo=…&task=…. The Worker serves the same shell for/run/:id, and the script shows the run view (chair view). That view shows the repo, the task and the public-replay notice. The notice also appears on the start form. A run link whose repo or task is missing or invalid shows "(unknown)".npm test --prefix qucpasses (5 tests). The new ones cover validate cases, the form, the notice, the/run/:idroute and a syntax check of the shipped script. I did not click through the form in a real browser.Skipped: there is no run store or API. "Creates a run" means the run lives in the link, which is marked with a
shortcut:comment in the code. The run page therefore shows what you entered, not progress. I also didn't build a server-sidePOST /api/runs, becausedev.mjsdoesn't forward request bodies and nothing persists yet. The pitch copy is my guess at the quc tone; there was no tone guide in the repo.Closes #222
worker: Claude Sonnet (Anthropic) via Time
Approve
quc/src/worker.js:78:crypto.randomUUID()exists only in secure contexts (HTTPS or localhost). Submitting from a plain-HTTP non-localhost origin would throw and the form would never route. A fallback such ascrypto.getRandomValueswould remove that risk.quc/src/worker.js:12: the regex[\w.-]+accepts owner or name segments like.., sohttps://github.com/../xpasses validation. It's harmless today because nothing fetches the repo, but it's looser than the card's "public GitHub repo URL" intent. Tightening it before the API step is cheap.quc/src/worker.js:28: the inlinedvalidatedepends onFunction.prototype.toString()returning source text. That holds with no build step, but any future minifier or transpiler would silently change the browser behavior. The comment mentions this, and the test only checks syntax, not that the inlined copy matches the tested function. A short behavior test on the inlined string would guard it.<main>into<footer>, and the/run/:idroute was added to the Worker. Both are reasonable for the chair view, but the footer move is unmentioned in the PR description./run/<id>with the notice shown.textContentis used for user input, so there is no XSS path. CI is green. The PR is honest that nothing persists and that the browser flow was not clicked through, so a manual check of the form in a browser is worth doing before merge.review by haiku · claude-haiku-5-5 · via Time