Verification status — 31 October 2026 UTC

Verified locally

• 512 Python tests passed for the current suite. This includes the revision-hardening release’s 489 tests covering roles, visibility, card/history rules, strict revision inputs, malformed identities, concurrency simulation, DataK3 adapter contracts, Models responses and YAML validation, plus 23 template/schema/resource-binding guardrail tests. The guardrails also run with Python optimization enabled; they do not emulate DataK3 or prove fresh-org provisioning. One upstream Starlette/AnyIO deprecation warning.
• All three simulated-DOM suites passed, including revision-bound menu/drag/editor/dependency behavior, filters, UTC my-week, viewer controls, literal text rendering, duplicate suppression, keyboard move, stale saves, searchable references, membership removal confirmation/cancel/failure/repeated clicks, expanded audit details and interrupted/reopened dialogs.
• Read-only name/reference lookup, ambiguity/prefix collisions, owner-only membership removal, unassignment/audit rollback, and explicit MCP tool annotations are covered locally. The owner lookup checks below add connected-client evidence; ambiguity cases, membership removal and broader role flows are not claimed as verified through that client.
• JavaScript syntax, Python compilation, dependency consistency and manifest parsing/shape checks passed.
• Local tests use isolated fake data/AI; they are not a substitute for cloud integration evidence.
• Official starter source is 2815f0bbc39ae589ff78be4dfcd87757e7cfe268. Official CLI 0.1.91 was release-signature and checksum verified.

Connected ChatGPT — 31 October 2026

• After approval of the specific pending ChatGPT client and the account holder’s sign-in, the legitimately connected Relayboard tools were available in ChatGPT. At approximately 04:14 UTC, my_boards returned the synthetic demo board with the signed-in user’s owner role. This used the connected client, not a substituted CLI or service-account credential.
• A reversible move_card test moved one synthetic card from To do → Doing at 04:17:20 UTC using observed revision 12; the response and fresh show_board read showed revision 13. A second call used revision 13 to restore Doing → To do at 04:18:09 UTC, returning revision 14. Fresh board/activity reads confirmed all three cards’ original business fields, retained baseline history and exactly two added move events. The intended revision/history changes were retained, not erased.
• At approximately 04:20 UTC, connected read-only checks also resolved the board by name and the card by reference, returning the canonical card ID and current revision. My-week and overdue reads returned the expected synthetic assigned work.
• This establishes a functioning connected ChatGPT owner read/write path for these calls against the application code introduced in df0a364 (unchanged by the later documentation/validation-only releases). It is not a recording of the full walkthrough, an independent audit of authorization-code/PKCE internals, scopes, refresh/revocation behavior, or a test of Claude, every MCP action, checklist writes, membership changes or member/viewer/outsider sessions through ChatGPT. No private identities, tokens or raw connector responses are published here.

Mandatory revisions — hosted release df0a364

• Application commit df0a364183046a0b295af402ca15fea5d545c880 passed all four CI checks (test/build/deploy/remix) and activated Ignite version 8. CI itself reported 489 passing Python tests; local verification also passed all three simulated-DOM suites, syntax/compilation, template shape and the official CI validator. The following evidence concerns that application code, not every historical client or future instance.
• A fresh private baseline captured 1 board, 3 cards, 0 memberships and 19 audit rows. No schema migration, new account, credential, service account or paid inference was needed. An initial post-deployment read-only DataK3 request timed out waiting for a connection; a later read succeeded with all records unchanged. The timeout cause was not established.
• Through the existing owner browser session, one revision-bound save changed synthetic description, assignment and a manual checklist. A second tab held the older revision: its edit, dependency-save and retained Move-menu attempts each displayed the stale-card refusal. DataK3 showed exactly one successful mutation/audit and one board-guard increment across the successful write plus all three rejected attempts.
• A valid dependency save advanced the same open editor's revision; its subsequent metadata/assignment/checklist save succeeded. Removing that temporary dependency worked through the normal multi-select control. A real pointer drag moved the card to Doing, then the Move menu restored it to To do. Reload showed all three cards in their original lists.
• Final DataK3 comparison preserved every original card business field, both untouched cards in full, board business fields, memberships and all 19 baseline audit rows. Only the tested card's revision/update timestamp and the board guard revision advanced. Six intentional test writes produced six retained audit events; no temporary checklist or dependency remains.
• Live unauthenticated schema probes on edit/move/blocker routes rejected 12 missing, boolean, float and string revisions with HTTP 422. Three otherwise-valid integer probes returned 401. These validate schema/auth refusal ordering, not new authenticated-role or external-MCP-client flows.
• The ordinary app loaded and its current UI flows worked. Direct browser navigation to the JavaScript asset was blocked by the managed browser; no bypass was attempted, and independent byte-for-byte serving-asset comparison is not claimed. Exact-commit CI/deployment status and observed live behavior are the available release evidence.
• At the initial deployment check, no external client, new live MCP mutation/role identities or mobile testing was performed. The later connected ChatGPT owner test is recorded separately above; other client/role and mobile coverage remains unverified. Earlier bearer-token/role tests below remain historical. Read the intentional breaking-change and safe-retry guidance in REVISION-CONTRACT.md.

Checklist release after baseline a2c69fa

• Base read-only clone: https://git.dodil.io/north-scape/relayboard, HEAD a2c69fafd8f52a883a95d3ed0d8d9ded61d7370e. The older private starter-based checkout was not used as the implementation baseline.
• Added persisted checklist data, audited atomic replacement, strict revision validation in web/MCP, a new explicit update_checklist action, and bounded read-only AI suggestions. Summary context now includes resolvable dependency IDs and checklist counts.
• Added browser draft selection/add/edit/completion/removal, explicit Save/Cancel semantics, progress and unfinished-blocker badges, and dialog-generation protection for delayed AI/blocker/summary results.
• 179 Python tests and both simulated-DOM suites pass against this working tree. Coverage includes permission denials, stale/malformed revisions, rollback, stable IDs, limits, literal hostile strings, duplicate clicks, cancel/reopen, delayed response/error isolation, frozen controls during saves, and duplicate-inference suppression. Independent review reproduced three interrupted-save/control-lifecycle defects; all were fixed and regression-tested, including an AI answer arriving during a failed save. JavaScript syntax, Python compilation, dependency consistency and template checks also pass.
• A real localhost HTTP smoke test passed for preview startup/assets/security headers, read-only fake AI, explicit checklist save/completion, stable IDs, preserved description, stale-revision conflict and checklist audit. The localhost preview was stopped afterward; this was not a browser or Dodil integration test.
• Authorized hosted-demo preparation on 31 October: verified Free hard caps, backed up the four Relayboard tables privately (1 board, 3 cards, 0 memberships, 16 audit rows), checked row counts and hashes, and applied only migration 002 once after confirming the column was absent. All pre-existing fields still matched their backups; each existing card read an empty checklist. The previous deployed app reloaded all three cards successfully after the additive change. No new account, service account, or paid service was created.
• All four CI checks passed for checklist application revision bf441d8921c80c5e8f07dcc38a42f888b225f6c6; Ignite activated version 6. The deployed editor loaded the existing three-card demo with empty checklists.
• Live browser/DataK3 checks passed: a canceled manual draft left every original card field unchanged; real Dodil AI returned five suggestions, two were explicitly selected and added to the draft, and a database read proved this still saved nothing. Only Save card persisted them. Completing one step survived reload with the same stable step IDs. The original titles, descriptions, assignees, dates, labels and lists remained unchanged.
• A second browser tab opened at the earlier revision tried to overwrite the checklist after a successful completion save. It received the stale-edit refusal; checklist, revision and audit count remained unchanged by the rejected save. The two successful writes each added one audit event, and the browser’s expanded history displayed the real checklist before/after values.
• Anonymous checklist PATCH and MCP requests returned 401. No new test identities or membership grants were created. Checklist-specific live member/viewer/outsider flows and checklist writes through an external assistant remain unverified; the later connected ChatGPT move test above does not cover them, and local permission tests are not a substitute.
• The broader historical role/concurrency evidence below belongs to the previously tested releases; the checklist-specific live evidence is recorded above.

Verified on Dodil

• Dedicated Relayboard repository, DataK3 bucket, appid pool and scoped app service account were provisioned by the official starter remix. The empty starter bucket received the six additive schema fields before upgrading the app.
• CI test/build/deploy/remix checks passed for the tested application revision b235c6a061cba0d0b85db368f2d21a22183dc470 (including 81 Python tests). Subsequent documentation-only revisions are traceable through the repository checks. Official CI validation found no problems, and the official remix validator accepted the manifest.
• appid signup/sign-in and the automatically registered Ignite callback worked. The authenticated owner created a board and two synthetic cards through the deployed browser UI.
• Card title, description, assignee, UTC due date, labels and list movement round-tripped through real DataK3 using the app's scoped service account and TLS verify-full. Records survived reload, a second browser tab, and a new Ignite pod after the CI redeployment.
• Board creation, card creation, edits, moves and dependency changes produced audit rows. A stale edit returned HTTP 409 without overwriting newer data or adding an audit event.
• Two competing writes from independent editors, with the same card revision, yielded one success and one serialization conflict. The stored revision increased once and only one new audit event appeared.
• Concurrent opposing dependency links yielded one success and one serialization conflict; only one direction was stored, with one audit event. No dependency cycle was committed in this test.
• Live browser checks passed for desktop layout, cancel-without-saving, search/reset, UTC overdue and my-week filters, list-selector and keyboard moves, completed-card overdue exclusion, and reload persistence. A real pointer drag also moved a card across columns and persisted; mobile viewport testing remains unverified.
• Real Dodil Models calls returned a Kimi K2.6 checklist and board summary, plus a Jina Embeddings v4 semantic match. The initial summary exhausted a 700-token output allowance; the fix raises the bounded allowance to 2048 and rejects empty/truncated output instead of presenting it as success. The repaired live summary returned substantive progress, risks and next steps for the synthetic board.
• Three temporary, approved appid users exercised member/viewer/outsider identities through real HTTP and MCP bearer-token requests. All 49 identity/visibility/denial checks passed: viewers and outsiders could not mutate cards or membership; members could not grant access; outsiders could not read boards/history. The denied attempts added no audit events. A further 16 positive checks verified real MCP creation, edit, move, assignment, my-week/overdue, dependencies, audit, ownership and owner-only access grants; three additional outsider AI requests were denied before inference. Test accounts, grants and extra QA objects were removed afterward; refresh sessions were revoked and deleted-account password sign-in returned 401. The original three-card demo and owner login remained intact. Previously issued bearer tokens remained accepted briefly beyond their stated expiry, then all returned 401 on identity, board-list and direct-board requests by the follow-up check. Temporary passwords/tokens were erased. Immediate token revocation is not claimed.
• Anonymous data/MCP calls and unauthenticated forged X-Dodil-User requests returned 401. A signed-in outsider with forged owner identity headers still received 404. Health and OAuth protected-resource metadata returned 200. These tests do not prove every authenticated gateway trust-boundary case.
• Free-plan hard caps were confirmed in the console; no upgrade or payment action occurred. The public rate sheet omits the current K2.6 multiplier, and the console did not expose a remaining LLM-credit counter. Remixers must verify their own quotas; this is not a capacity guarantee.

Remaining live gates — not claimed as passed

• Independent inspection of OAuth authorization-code/PKCE internals, requested/granted scopes and refresh/revocation behavior; Claude or other external clients; broader actions and member/viewer/outsider sessions through ChatGPT. The connected owner read/move/restore test above is real client evidence, but does not establish those cases. Historical bearer-token role tests remain distinct. Per-role browser-control presentation is still unverified.
• A genuinely fresh-organization remix of the final repository. An official valid template/non-mutating ready plan is not an executed fresh-org test.
• Mobile/responsive testing; the managed browser blocks DevTools/device emulation and no supported viewport-resize control was available. Full interrupted navigation/repeated-click/network-failure tests on the deployed browser also remain.
• Raw-container non-public reachability, broader forged-header cases, and failure-injected multi-table rollback beyond the demonstrated transaction conflicts.
• Contest eligibility/deadline confirmation and manual submission through a permitted channel. No contest entry has been submitted automatically.

Known hardening gaps

• Existing-card edit schemas now require strict integer revisions through web and MCP; clients omitting/coercing them must upgrade. This does not add optimistic-concurrency tokens for board/membership operations, durable idempotency, or proof for every live client/rollout scenario.
• No durable create-request idempotency key; lost responses followed by retries can duplicate a create.
• No owner transfer, custom lists, server-side pagination or app-level rate limits.
• AI summary and similarity are capped at 100 cards per board; embeddings are not persistently indexed.
• Name/reference discovery returns at most 20 matches but currently scans the signed-in person’s visible cards; repository-level search/pagination is needed for large workspaces. Reference-prefix collisions are explicitly ambiguous, not globally unique guarantees.
• Original-starter buckets need migrations 001 then 002; pre-checklist Relayboard buckets need only 002. Fresh remixes use the complete schema.sql. The hosted demo has received migration 002; other existing copies require their own authorized migration.

These limitations are stated deliberately. A deployed release candidate is not a fully verified contest entry, production security certification, or guarantee of an award/payment.