Relayboard

Less status chasing. More shared momentum. Relayboard gives a small team one clear place for what is next—and lets its AI assistant work on the same cards, through the same permission checks.

See the board, ask what is blocking the launch, move the next task forward, and check the activity trail. No parallel chat-only task list to reconcile.

Live release candidate, not a submitted entry. Browser, DataK3, AI and role-aware MCP transport have live test evidence. A connected ChatGPT client also passed owner reads and a revision-bound move/readback/restore test. A genuinely fresh-organization remix is still pending; OAuth protocol internals and broader client/role coverage are not independently verified. See the exact verification status; local adapter tests are not cloud-service proof.

Reviewed checklists, now live

This release extends baseline a2c69fafd8f52a883a95d3ed0d8d9ded61d7370e with reviewed, persistent checklists, checklist progress, blocker badges, and interrupted-request protections. The initial checklist release passed 179 Python tests and both simulated-DOM suites. The hosted demo received migration 002 after private backups and preservation checks; its previous app version still read all existing cards afterward. Live testing passed for AI review/select/add-to-draft, explicit save, completion and reload persistence, stable step IDs, canceled drafts and rejected stale edits. See the exact evidence and remaining limits in verification status.

Mandatory card revisions

This release additionally requires a strict integer expected_revision on every existing-card edit through web or MCP. The revision-hardening release passed 489 Python tests and all three simulated-DOM suites; the current suite passes 512 Python tests after additional template guardrails. Application commit df0a364 also passed exact-commit CI and hosted owner checks for revision-bound edits, dependencies, drag/menu moves and refused stale writes; the original demo data was restored. Earlier checklist and MCP role evidence remains separately dated in verification status. Clients that omitted or coerced revisions must upgrade. No database migration is needed. See the revision contract, compatibility notes and verification limits.

Demo and source

• Open Relayboard — sign in or create your own app login; other people’s boards are not shared automatically.
• Dodil repository — MIT-licensed source and remix template.
• Two-minute walkthrough — a reproducible small-team story, expected results, and clearly separated verified versus pending steps.

Try the browser in a minute

1. Open the app and create an app login. This is separate from a Dodil builder account; your boards start private.
2. Create Friday launch, add Prepare the walkthrough, assign it to yourself, and choose an explicit due date.
3. Move it to Doing with drag-and-drop or the keyboard-friendly Move menu. Open Activity to see who changed it and what changed.
4. Try My week, then Briefing for an AI-assisted progress summary. AI features use the deployment organization’s Dodil Models quota; check your free allowance first.

For teams: owner-controlled sharing, a readable change trail, and one task list across interfaces. For builders: inspectable MIT source, real Dodil integrations, and a remix manifest that provisions isolated app resources. Connected ChatGPT owner reads and reversible moves have live evidence; a genuinely fresh-org remix and broader client/role checks remain outstanding.

What works in the implementation

• Owner-controlled board membership: owner, member, viewer. Owners can remove access with an explicit confirmation; assigned cards become unassigned and the change is audited. The appid pool is the organization’s sign-in workspace; board membership defines visibility within it. Owners invite by granting an email address access; the person signs in through appid. This does not send invitation email or create an appid identity.
• Boards with three deliberately simple lists: To do → Doing → Done.
• Cards with title, description, assignee, due date, labels, drag-and-drop, and a keyboard-accessible Move selector.
• Actor/time/before-and-after audit history with expandable change details in the browser. A card write and its history are one DataK3 transaction.
• Twenty MCP actions with explicit read/write/side-effect hints for clients. A viewer cannot mutate; an outsider gets no private board/card data. Routes and tools call the same application layer.
• Stable readable card references such as RB-12AB34CD, visible and searchable in the browser. Read-only resolve_board / resolve_card tools find exact names, titles or references and return IDs/current revisions. Duplicate names or prefix collisions return candidates, never a guessed write target.
• UTC overdue flags, “my week,” dependency cycle prevention and transitive unfinished blockers. Card badges expose unfinished direct blockers and checklist completion without opening every editor.
• Dodil Models adapters for checklist suggestions, short board summaries, and embedding-based similar cards. Review suggestions, select useful steps, add them to a card draft, then explicitly Save card. Stored checklists support completion, editing and removal with stable step IDs, revision checks and an audit trail. AI requests never execute commands or silently save content.
• Responsive zero-build interface, same-origin assets, literal text rendering, semantic dialogs, loading/error states, optimistic revision checks, and no analytics or third-party browser assets.

The three-list scope is intentional: a clean core rather than a second administration product. Semantic matching and summaries are capped at 100 cards per board. Every production record belongs in DataK3; only tests and the explicitly local preview use memory.

Run the tests

Python 3.12 and Node (for the JavaScript syntax check):

python -m venv .venv
.venv/bin/python -m pip install -r app/requirements.lock -r requirements-dev.txt
PYTHONPATH=app .venv/bin/python -m pytest -q
npm ci --ignore-scripts
npm test                       # simulated DOM only, not browser/layout verification
node --check app/boards/doors/static/app.js
.venv/bin/python scripts/check_template.py

requirements.lock records the exact locally tested dependency resolution. requirements.txt preserves the starter’s top-level dependency constraints for maintainers. No account or AI key is required for these checks. The template script is a local structural check, not Dodil's official validator.

Private local preview

PYTHONPATH=app .venv/bin/python scripts/preview.py
# Open http://127.0.0.1:8080

The preview has fake sample work, fake AI, no authentication, and ephemeral storage. It binds only to localhost and is excluded from the production image. Never expose it publicly. Production has no DEV_USER bypass.

Dodil integration and remix

This project extends the MIT-licensed official starter, source commit 2815f0bbc39ae589ff78be4dfcd87757e7cfe268. The starter copyright notice is preserved. It uses only the required Dodil production services:

.dodil/remix.yaml provisions one ${repo}-data bucket, ${repo}-users pool, and bucket-scoped service account with Models access. Credentials are CI secret references, never source values. .dodil/deploy.yaml keeps the user pool attached and public_invoke: true for OAuth discovery; the app rejects missing identity on its data routes and assets.

Use a repo name 18 characters or fewer, leaving space for remix suffixes and the bucket's 25-character limit. relayboard fits. Keep the resource conflict policy at its default fail.

Remix into your own organization

Use an organization you administer, preferably an empty test organization. After signing in with the official Dodil CLI, replace <your-org> below:

dodil git remix check north-scape/relayboard
dodil git remix plan north-scape/relayboard --to-org <your-org> --name relayboard
# Review the plan, including any organization CI secrets the template can see.
# The next command CREATES resources and deploys; run it only when authorized.
dodil git remix north-scape/relayboard --to-org <your-org> --name relayboard

The remix starts private by default; these instructions do not publish your copy. Follow the run to success, then follow the sign-in checks below. Fresh copies use the full schema automatically—do not run the upgrade migrations on them. If the repository name was suffixed, use that final name for every later pool/app command. A valid manifest or ready plan is not proof of a successful fresh-organization run. The local template check also verifies required schema columns and resource/secret bindings, but does not emulate DataK3 or confirm AppID provisioning defaults.

Before an authorized first publication

This section is a checklist, not a claim that publication has occurred:

1. Account holder verifies contest/platform eligibility and authorizes the desired account/org, public MIT repository, deployment, and submission. Do not automate Freelancer without the platform permission its terms require.
2. Read current dodil guide, dodil guide remix, and dodil://k3/sql. Prepare a test copy using scoped credentials. Provision the updated schema before running this code against it. A bucket created by remixing the original starter needs the additive migration below; editing schema.sql alone does not migrate an existing bucket.
3. Run the tests, dodil git ci verify, then the official dodil git remix check <org>/<repo> and non-mutating remix plan. Push/deploy only with authorization.
4. Publish in the account holder’s own Dodil organization, MIT licensed, with dodil-challenge and dodil-challenge-boards topics. The remix manifest topics do not prove the live repo has them.
5. Test a genuinely fresh-org remix of the final public repo. A successful build alone is not the contest gate.

After the remix: sign-in step

Select and verify the target organization first. The remix's --to-org chooses where it creates resources; it is not a safe substitute for selecting the active CLI session. AppID commands derive the organization from that session. Replace <your-org> with the remix target and <repo> with the final repository name printed by the run (including any suffix), then run:

dodil auth use-org <your-org> && \
  dodil auth status && \
  dodil appid pool get <repo>-users -o json

Stop if switching fails or the identity/organization is not the intended one. The pool issuer must be https://appid.dodil.io/<your-org>/<repo>-users before running any connection, settings, user or client commands below. A missing stored session may require interactive sign-in; do not fall back to the original org.

The current CLI 0.1.91 remix guide says Dodil Git 1.6.11+ automatically registers the app callback during deployment. Inspect the deploy log. If it says the callback was not registered, execute the exact fallback command it prints once; preserve existing pool callbacks. Obtain the actual URL from dodil ignite app get, never construct the hostname by hand.

Check the sign-in connection as well as signup policy. The official AppID quickstart explicitly enables email/password with --with-local; the remix manifest only declares a pool and roles. Do not assume a new remixed pool already has a local connection:

dodil appid connection list <repo>-users
# Only if local email/password sign-in is missing, and you administer this new pool:
dodil appid connection add <repo>-users local --enabled

If a local connection exists but is disabled, review why before enabling it; do not overwrite an existing organization’s authentication policy. These commands use the currently selected Dodil organization. Our deployed pool has an enabled local connection; this check is documented for fresh remixes, not claimed as an executed fresh-org test.

A new pool permits signup by default. If the account holder has disabled signup, an authorized pool administrator must create/invite the first people through appid. Never put passwords in the README, repository, or demo. Then sign in at the actual Ignite URL and create a board.

For MCP, add https://<actual-app-host>/mcp as a custom connector. appid handles OAuth; a newly registered client may be pending. Approve the verified client once with dodil appid client list <repo>-users and dodil appid client approve <repo>-users <client-id>. This client approval is separate from both the browser callback fallback and the person’s sign-in/consent. A connected ChatGPT client passed owner read and move/readback/restore checks on 31 October 2026. This does not independently audit OAuth protocol internals or establish other clients, roles or fresh remixes; see the scoped connection evidence.

Existing starter bucket migration

Fresh remixes use the complete schema.sql and need no migrations. Existing buckets must be upgraded before deploying this code:

The second migration adds only cards.checklist with the JSON-text default []; existing cards keep their data. These scripts are not automatically applied and are not safely rerunnable. Review the actual schema and obtain backup/approval before authorized execution. Verify defaults, reads/writes and transaction history on real DataK3 before deployment. The hosted Relayboard demo received migration 002 on 31 October 2026 after backup and preservation checks. This does not migrate anyone else’s copy.

Production environment

Set only through approved secret/config references: BUCKET, DODIL_USER_POOL, DODIL_SERVICE_ACCOUNT_ID, DODIL_SERVICE_ACCOUNT_SECRET, and the endpoint settings in the deployment manifest. PostgreSQL defaults to TLS verify-full with the system CA bundle; validate the actual endpoint certificate before go-live. Never expose the container port directly: the app relies on Dodil’s gateway stripping forged identity headers and injecting the appid identity. This trust boundary requires live testing.

Try these MCP requests

• “Resolve the Ops board by name; if more than one matches, ask me which one. Then show it.”
• “Add ‘Send invoice’ to Doing on Ops, assign it to me, due Friday.”
• “What’s on my plate in the next seven days? What’s overdue?”
• “Resolve card RB-12AB34CD, then move the unique match to Done using its current revision.”
• “What is blocking the launch card?”
• “Suggest a checklist, but do not save anything yet. After I approve the steps, use update_checklist with the current card revision and retain existing step IDs.”
• “Find related cards and summarize the board.”

Resolution is read-only: existing-card edits require canonical IDs and the observed integer revision. References are stable UUID prefixes, not sequential card numbers; a rare collision is reported as ambiguous. Lookup returns at most 20 candidates with an explicit total/truncation flag.

No tool accepts arbitrary SQL, raw table access, or a caller-supplied user identity. Dates resolve to explicit YYYY-MM-DD values; my-week includes overdue and undated assigned work and excludes completed work.

Design, limitations, and next steps

Read design notes, acceptance checklist, and verification status. In particular, this is not hardened multi-tenant SaaS: add durable idempotency keys for create retries, pagination/rate limits, owner transfer, and broader real-engine integration coverage before broad use. The first next step is the authorized fresh-org remix test—not more speculative features.

MIT. No earnings or contest outcome is guaranteed.