Conversation
feat(graph): complete live Subgraph MCP recovery proof and qualify The Graph
docs: define Arc Circle qualification path
Gate P5: merge frontend acceptance implementations
feat(worker): add production runtime
feat: package Gate P6 release candidate
fix: use pnpm version
feat(auth): Privy operator authentication and console gating
feat(web): Behance-grade minimalist dark glassmorphism landing and console
feat(auth): open wallet authentication with wildcard allowlist and UI polish
fix(web): resume supplier results and copy wallet address
fix(web): resume supplier results and copy wallet address
fix(web): resume supplier results and copy wallet address
fix(web): remove automatic resume polling
feat: add MCP wallet signing handoff link
README had drifted 23 commits behind develop. Bring it back to the shipped surface and give it the product's own nav panel as a banner. Documentation corrections: - Add packages/brand to the repository layout and describe apps/api's MCP endpoint and personal-credential role. - Replace the retired four-tab console and "Tools" section with the five cabinet sections that exist today, and document the /docs/mcp route. - Add the user-wallet, MCP, and profile-credential routes to the API table, and note that the transport and operator routes sit outside the frozen v1 contract pack. - Describe the non-custodial MCP payment flow and digest-stored personal bearers in a new Agent access section. - Record that a browser caller's workspace is derived from its verified Privy subject, and that every committed settlement captures Graph evidence through a durable outbox job with a backfill for older settlements. - Repair a duplicated sentence fragment in Project status and add the user-wallet and MCP rows to the status table. The banner is not hand-drawn. scripts/render-nav-panel.mjs reads the palette from packages/brand/src/tokens.css, the mark geometry from CommitRing.tsx, and the nav labels from apps/web/src/App.tsx, then emits one SVG per theme. GitHub strips CSS from Markdown, so the README selects between them with a <picture> element. tokens.css remains the only source of a brand colour.
Supplier delivery finishes in the worker, after the browser has already read the request list, so a request whose delivery was still PENDING at read time kept saying "Retrieving result" until someone pressed refresh — long after the result was durably available. Whether it looked right depended only on whether the worker beat the page load, which is why it worked intermittently. The list now re-reads itself while any delivery is PENDING: every four seconds, fifteen attempts, then it stops and leaves the manual refresh as the way to look again. The reads are GET /v1/jobs only. They never call the resume endpoint and never submit a payment, so at-most-once settlement is unaffected, and they do not raise the loading flag, because the spinner, the disabled button, and the tab fade belong to a read the operator asked for. This partially reverses a2903a1, which removed automatic polling after a report of unwanted traffic. The bound and the pending-only condition keep both reports satisfied; the resume control that commit removed stays removed. The browser spec asserted an exact list-read count, which a timed re-read makes timing-dependent; it now asserts a lower bound and still asserts that no resume request is sent.
fix: surface Graph evidence for site payment outcomes
Resolves one README conflict. PR #139 rewrote the same activity paragraph this branch had edited. Keep develop's description of the automatic per-payer-wallet subgraph query and the per-request audit rows, and fold this branch's note that Graph evidence capture runs as a durable idempotent outbox job with a backfill for settlements that predate it. Both statements describe code on develop: capture_graph_evidence in apps/worker/src/worker.ts and migration 013_backfill_graph_evidence.sql. Re-running scripts/render-nav-panel.mjs against the merged tree produced byte-identical banners, and the merged API routes still match the table.
fix(web): re-read a pending delivery until the worker reports the result
docs: refresh README and add front-end derived banner
A committed job whose delivery reached PENDING could be left with nothing able to move it. The worker no-ops a payload whose delivery_attempt no longer matches and then marks the outbox row DELIVERED, and resumeDelivery re-queued only NOT_REQUESTED or RETRIEVAL_FAILED, so the job kept a committed payment, an unretrieved result, and no path forward. PENDING alone is still not treated as resumable. The deciding evidence is whether a fulfill_supplier_order row is still queued for that job: a row a worker currently holds is status PENDING and so counts as queued, which means an in-flight retrieval is never duplicated. Only a job with no such row left is re-queued, under a fresh delivery_attempt that fences the old retrieval. The claim is a compare-and-set against the state read under the job's FOR UPDATE lock, so two concurrent resumes cannot both take one delivery. No payment work is created on this path; the committed settlement is untouched.
The full-width nav strip carried the network badge, token badge, theme control and workspace link into a README where none of them mean anything, and at README width the whole row rendered small. Keep only the brand lock-up — the commit-ring mark, the wordmark, and its SETTLEMENT ENGINE tag — on the same rounded panel, and scale every length by one factor so the proportions stay exactly those of `.top-nav`. The banner is still generated, not drawn: the palette comes from tokens.css, the mark geometry from CommitRing.tsx, and both labels from App.tsx. The canvas is 381x112 and sized to its own content, so the tag clears the panel edge with the fallback fonts GitHub renders.
docs: reduce the README banner to the brand lock-up
fix(jobs): recover a delivery stranded in PENDING
Updated the README to include a centered picture element for the brand lock-up.
The Graph activity query is sent with the shared server wallet alongside the workspace's user wallets, so a stored observation also carries transfers made for other workspaces. Settlement and uncertain counts were SQL-scoped to the workspace while the unmatched transfer count was taken from the whole observation, so Payment proof reported one workspace's 11 settlements next to 40 unmatched transfers drawn from every workspace. Filter the observed transfers to the ones this workspace can own before they are matched, listed or counted: the sender is a workspace payer wallet, or the transaction hash is already recorded on a workspace settlement, job or attempt. The attempt hash keeps a stranded server payment visible as unmatched evidence.
…ansfers fix(activity): scope indexed transfers to the workspace
The worker drains the outbox on its own timer rather than per request, so it only works while its process is alive and holding CPU. The documented deploy omitted both flags, and a deployment without them fails quietly: payments still settle through the API, but supplier deliveries sit in PENDING and requests stay on "Retrieving result". The failure is intermittent, which makes it easy to misdiagnose as a UI or state-machine fault. Any request that reaches the service boots an instance, and startup drains the backlog before the timer takes over, so the queue appears to clear itself and then stalls again.
docs: require min-instances and no-cpu-throttling for the worker
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
oneshot | 8e89d5f | Sep 13 2026, 03:05 PM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.