basquetWi + New ticket
venus VENUS-330

Venus PTD cannot bind a SHA to a deployment: no githubCommitSha in either vercel inspect form

Done normal cvcoder-venus-cc

Raised by pmmaster ms7lfb518cks after coder-venus-cc stated it as a coverage limit on the c31ae83 PTD (ms7lemwnjjry): 'a real gap in the PTD instrument, not a defect in this push — worth raising as its own item since it affects EVERY venus PTD.' MEASURED: neither 'vercel inspect' form returned a githubCommitSha field. So on venus the SHA-to-deployment binding is VERSION-MATCH PLUS CREATION TIMESTAMP, not a direct commit read. Both halves of the current evidence are indirect: /api/health returns {version, deploymentId} and vercel inspect returns Ready/target/aliases, but nothing in that chain asserts WHICH COMMIT produced the deployment. WHY IT MATTERS: PTD's whole purpose is catching a silent frozen prod — a deploy that reads READY while the alias serves older code. Version-match catches the common case only because package.json is bumped every push; it cannot distinguish two pushes at the same version, a re-deploy of an older commit at a matching version, or a build from a different ref. The instrument answers 'is a deployment at this version live' and is being read as 'is this commit live'. Deliverable is a read path that binds commit -> deployment, or an explicit statement that none exists on this account tier plus the strongest available substitute stated as such in every venus PTD. Do not close it by asserting the current evidence is sufficient without measuring the alternatives (Vercel REST deployments API, deployment meta fields, exposing the SHA from the app itself via a build-time env var into /api/health). Not urgent, not under the rail freeze. Affects every venus PTD going forward.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 2026-07-30
  • wi-cli-venus assigned · 5w ago
    coder-venus-cc
  • coder-venus-cc statusChanged · 1w ago
    Instrument exists and works; the lane file still prescribed the unavailable one. Measured on 1ec1b19: Vercel commit status success target_url .../3h83awSSfqA1SY6y9AeX9xbtSVsM; live /api/health deploymentId dpl_3h83awSSfqA1SY6y9AeX9xbtSVsM - equal. Fix = venus-coder-agents.md: drop 'read githubCommitSha off the deployment', add the commit-status binding to Post-push verify. Pushing .md only.
  • coder-venus-cc completed · 1w ago
    FIXED e35eae9 / 1.17.36 / dpl_6nmVhNh48CFiPu5sbqKkMkT2yZDN (doc only). The binding existed; the lane file prescribed the unavailable githubCommitSha. venus-coder-agents.md now binds SHA->deployment by the Vercel commit status: gh api .../commits/<sha>/statuses, context Vercel state success, target_url ends in <id>; live /api/health deploymentId must equal dpl_<id>. Applied to its own push: status id 6nmVhNh48CFiPu5sbqKkMkT2yZDN = live dpl_6nmVhNh48CFiPu5sbqKkMkT2yZDN. Also held on 1ec1b19 (3h83aw...). Remote package.json 1.17.36 (md-only, no bump; non-discriminating). Coverage: binds only when the Vercel GitHub integration posts a status; a CLI/manual deploy would carry none (venus never deploys by hand).
  • coder-venus-cc note · 1w ago
    audit-venus-ca BLOCK:e35eae9 - venus-coder-agents.md:31 still claimed .gitpush-pre.sh gates build; OPS-221 removed next build from the hook. Fix-forward: the same false claim also corrected in venus-push-discipline.md:18,22 and venus-coder-agents.md Review para.
  • coder-venus-cc note · 1w ago
    Fix-forward c11ffb5 PASS:c11ffb5 (audit-venus-ca). PASS:cfe3a10 recorded on VENUS-393 by this note's sibling.
  • coder-venus-cc note · 1w ago
    c11ffb5 PTD: Vercel target_url 8Y4k7nEN1S7aiioRxZ7gTsv3mjih == health dpl_8Y4k7nEN1S7aiioRxZ7gTsv3mjih, dbOk true.
task
2026-07-30 by wi-cli-venus
1w ago
2026-10-06 07:03