Show HN: Give our AI coding runner a real task and watch it until merge

mcp4mail is a real open-source product. A person writes the tasks, our runners program them — and you can check every step: the task, the pull request, the tests and the resulting code on GitHub.

scheduleThe site is deployed once a day — a merged change is on it on work days at around 18:00 Prague time (CET/CEST), not the moment you see it merged here.

In 40 days they delivered 179 finished tasks and are now waiting for the next assignment.

Runners run on our own machines. None of them has direct access to the main branch.

work_historyThe runners work on work days from 8:00 until 18:00 Prague time (CET/CEST) and often longer — outside those hours the panel is quiet.

Context: Launch-day task for Show HN (2026-10-21). New visitors will open issues; today .github/ has only dependabot.yml, pull_request_template.md and workflows – no issue templates, so reports arrive without the details we need.

Do:

1. Add .github/ISSUE_TEMPLATE/ with issue forms (YAML):

• bug_report.yml: hosted or self-hosted, version/commit, MCP client used, steps, expected vs. actual, relevant log lines (with a reminder never to paste passwords or tokens).

• feature_request.yml: problem, proposed solution, which tool it concerns.

• mail_provider.yml: provider name, IMAP host/port, whether an app password is used, error message shown in the app; link to the existing provider guides.

2. Add config.yml with blank_issues_enabled: false and a contact link to SECURITY.md for vulnerabilities (if SECURITY.md is not merged yet, link to the GitHub security advisories page of the repo).

3. Mention the templates in CONTRIBUTING.md in one sentence.

Acceptance criteria: "New issue" on GitHub shows the three forms; forms validate (GitHub renders them without errors in the PR preview / after merge); bin/ci green.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Context: Launch-day task for Show HN (2026-10-21). "Run it yourself with docker compose" is a main promise of the README; HN readers will try it within minutes and comment if it breaks.

Acceptance criteria: a newcomer following only the docs gets a running instance; .env.example and docs match the code's ENV reads; findings listed in the PR; bin/ci green.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Context: Launch-day task for Show HN (2026-10-21). "Does it work with my provider?" will be a frequent question. The backlog refill tracks IMAP compatibility for Dovecot, Cyrus, Courier, Gmail, iCloud, Seznam, Zoho, Fastmail (guides in app/views/guides/content/, tests in test/; recent tasks #13679 Dovecot, #13680 Seznam, #13681 iCloud), but the README does not show it.

Do:

1. Add a short "Mail providers" table to the README (in or right after the "Mail accounts" section): provider, status (tested = there is a test in test/, guide = setup guide exists, untested), app password needed (yes/no, per the guide), link to the guide on mcp4mail.online if public.

2. Derive every row from the code/tests/guides – do not mark anything tested that has no test. Note Outlook/Exchange status honestly (only if covered by a guide or test; otherwise "untested").

3. Add one line inviting people to report a provider via the issue template (if merged) or a GitHub issue.

Acceptance criteria: table present, each status traceable to a file in the repo (list the files in the PR description), bin/ci green.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Context: Launch-day task for Show HN (2026-10-21). The README explains the safety model only in text; two screenshots make it understandable in seconds.

Do:

1. Produce two screenshots from the system tests (or a dedicated system test that saves them), with seeded fake data only – no real addresses:

• Mail accounts page with "Allow the AI to make changes to this mailbox" switched on and the permission checkboxes unfolded.

• The outgoing-message approval page (the page behind the link a user gets before an e-mail from send_message leaves).

2. Save them as optimized PNG/WebP under docs/images/ (keep each under ~200 KB), English UI.

3. Embed them in the README section "MCP endpoint: read-only by design" with descriptive alt text.

Acceptance criteria: two images in docs/images/, shown in the README on GitHub, no real personal data in them, bin/ci green.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Context: Launch-day task for Show HN (2026-10-21). Visitors coming from HN will move between the repo, the hosted site and https://mcptask.online/live. The hosted site must make the open-source and built-in-public story easy to find.

Do:

1. Check the homepage and the footer of mcp4mail.online (cs and en). If missing, add: a "Source code on GitHub" link to https://github.com/jchsoft/mcp4mail and a "Watch it being built live" link to https://mcptask.online/live (with ?language=en / ?language=cs according to the current locale). If links already exist, just verify they work in both locales and close the task with a note.

2. Add the i18n strings in cs and en (i18n parity check must pass).

3. Use rel="noopener" for external links; keep the existing design.

Acceptance criteria: both links visible on the homepage and in the footer in cs and en; system test covering their presence; bin/ci green.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Stable key: dogfood: unread since Monday (source: Dogfooding, backlog refill 2026-W44).

Imap::MessageSync#import_new_messages only fetches UIDs above MailFolder#last_synced_uid. A message's FLAGS are stored once, when it is first indexed, and never refreshed. When the owner reads (or flags) mail in their own mail client, the index keeps unread: true, so search_messages unread: true returns mail that is no longer unread. The same pass never notices messages expunged on the server, so they stay searchable until get_message fails with "message gone".

In sync_folder, after importing new messages, refresh the flags of already-indexed messages: UID FETCH 1:<last_synced_uid> (FLAGS) (batched like the import), update_all the changed flags, and delete index rows whose UID the server no longer returns. Use CONDSTORE/CHANGEDSINCE only if it stays simple; a plain FLAGS fetch is cheap enough for the 15-minute refresh. Mirror Gmail's per-gm_msgid copies the way FlagSetter does.

Extend test/services/imap/message_sync_test.rb with the fake IMAP server: a message's flags change between two syncs → the index follows; a message is expunged between two syncs → its row is gone. No setting, no new tool.

Why we ask for your e-mail: we'll e-mail you when the work starts, when the pull request is ready and when it's done. Nothing else, and it is never shown on this page.

Afraid AI will break your code? So are we. That is why a runner gets nothing you would not give a new developer on their first day: it works on its own branch and reaches main only through a pull request that passes CI – plus a person's review where the project requires it.

A person writes the brief. The runner takes what is ready — and when a task turns out to be bigger than one run, it sets it aside for a person instead of half-implementing it.

Work happens in isolation. The main branch is locked for people and runners alike.

A small, readable change linked to its task. Anyone can open it on GitHub.

Lint, security scan, unit and system tests. Red means it goes no further.

After green CI the change is merged; mcp4mail.online picks it up in the next daily deploy.

All time179 tasks done145 pull requests merged8,350 minutes of work

We do not hide red tests or tasks a runner set aside. They are exactly where you see the checks working.

The first CI run failed. The runner fixed it, and run 2 passed.

The whole project is open. Send the link to your most sceptical senior and let them go through the pull requests, the tests and the commit history. This is exactly how it would look at your company.

scheduleThe site is deployed once a day — a merged change is on it on work days at around 18:00 Prague time (CET/CEST), not the moment you see it merged here.

The same process, the same safeguards, your infrastructure. 30 days to try it, no credit card.

Onboard your AI developer

verified_userFree 30-day trial. No credit card. Cancel any time.