v1.0.1; no release image or GitHub release exists until publication completes. These notes describe the candidate’s product and migration behavior. Acceptance depends on exact-commit source and production CI, manual UI review, upgrade and restore evidence, and independent review of the release artifacts. Mill is intended for public source and image distribution.
Task lists
Tasks have no checklist or comment-editing feature. The initial schema contains only the supported v1 model. Operate → Boards opens an alphabetical card overview with separate Backlog, To Do and In Progress counts for each board. The Create Board button on this page creates a board. Each board has a task list using Backlog, Todo, In Progress, In Review, Done, and Won’t Do. Tasks have Task or Bug types, defaulting to Task, and retain stable links, Markdown, assignment, priority, due dates, comments, mentions, and activity. A theme-colored task icon or red bug icon appears before each task ID in the list. Search, combined filters, sorting, and pagination help find work. Search tasks sits above the table; filters and sort live in the secondary panel, with visible labels and accessible names. On smaller screens, the Filters button opens the navigation drawer. The ellipsis after New task opens Board settings or a separate Delete board confirmation. Tasks open on dedicated pages with independently saved fields and inline retry/conflict recovery. UI creation asks for Title, Type, Description and Assignee; REST/MCP retain the full creation contract. Type appears above Status on the task page and saves independently with Activity history. Existing tasks start with Task type and keep their identifiers and history. Board search, filters, sort, page and page size persist in URL parameters and task return links. Task edits and status changes use versions to reject stale writes. Members can permanently delete tasks; human administrators can permanently delete boards and their work. Deletion requires confirmation and cannot be undone in Mill. There are no archive or restore states. Kanban, editable statuses, manual board/task ordering, labels, task parents/subtasks, portable export/import, and email task notifications are excluded from v1. Upgrading preserves existing task and subtask records as independent tasks; unknown old custom statuses become Todo. Follow upgrade guidance and make a full backup first. The task actions menu includes Duplicate task. It opens a modal with a[Copy] title prefix, the original description, type and priority, Backlog status and an empty assignee. The user confirms creation after reviewing the fields. The copy has a fresh identifier and no due date, comments or previous activity.
Task properties include an optional Start date before Due date. Both are calendar dates, save independently with retry/conflict recovery, and can be set or cleared through REST and MCP. Existing tasks begin without a start date; duplicated tasks leave both dates empty.
People and client connections
First setup creates the administrator once. Teams use roles, invitations, profiles, time zones, sessions, passkeys as the only second factor, and single-use passkey recovery codes. Assignments and mentions produce in-app notifications in the compact header bell. Account and invitation email can be enabled with a configured SMTP server; without it, administrators share private invitation links and operators can use the documented recovery procedure. Task email notifications are outside this release. Personal and team API keys use explicit Read-only, Edit, or Administrative grants for REST and MCP; creation requires Name, Permissions, and Expires after (30 days, 90 days, 1 year, or Never). MCP OAuth creates a human-owned connection with approved read or read/write scopes and optional board restrictions. Clients do not need a separate identity to connect. There is no Agent directory, management, task assignment or filter in the application, REST or MCP. Personal keys and OAuth are revocable and enforce current membership and role; team keys are revocable and use their stored team policy. Identity, account security, membership, and credential management remain browser-only. Mutations support retry keys, versions, and bounded rate limits; task activity identifies the responsible person and distinguishes OAuth connections from human actions. Workspace-wide audit history is excluded. Navigation includes Account Settings and Team Settings. Personal keys belong to Account Settings; team keys and member management belong to Team Settings. Create invitation actions sit above member/invitation tables without redundant headings. Shared Avatars use email/name lookup with initials fallback; table lines, role/status Chips, explanatory text, and secondary/danger controls follow Towbar. Remote MCP and Backups widgets are removed; their operator and connection guides remain available.Self-hosting and release review
Separate API and UI images run as non-root processes. Compose starts the API and UI from one release version, connected to your existing PostgreSQL database. An optional overlay runs PostgreSQL too. Set only the database URL, application secret and public origin for the basic setup. Installations need Docker Compose and downloaded configuration files. Only the UI exposes a host port; it forwards same-origin REST, authentication and streaming MCP requests to the private API. Mill applies checksummed migrations at startup. Full PostgreSQL backup and restore preserve work, account state, notifications, and credentials; there is no portable-work export/import feature. The pre-launch migration sequence has been consolidated into001_initial.sql for fresh installations. Startup verifies its checksum and rejects databases using the retired sequence. Those private development installations must be converted using the maintainer procedure, preserving a recoverable copy of the original schema. The release is not an automatic upgrade from the earlier private candidates. Read upgrades before changing an existing installation.
The source CI gate runs documentation checks, formatting, lint, types, operations tests, real PostgreSQL tests, dependency audit, and build. The production CI gate exercises a disposable container installation, migration checks, persistent data, backup and restore, proxy behavior, and image security. Desktop and mobile routes in both themes still require manual review; there is no automated browser CI gate. Pre-launch conversion is verified separately against a recoverable source snapshot.
The release workflow requires a stable tag on current main, passing exact-commit CI, and a public repository. It publishes native AMD64 and ARM64 images to ghcr.io/avgeek-oss/mill-api and ghcr.io/avgeek-oss/mill-web, checks their indexes, aliases, labels, and anonymous access, then installs the paired immutable digests on both architectures. Only after both installation gates pass does it publish the GitHub release with mill-images.json. Use matching version tags with the image-only Compose file, or pin its images.api and images.web references; release publication does not deploy Mill to a server. A separate workflow can prepare source and image archives with source-manifest.json, release-manifest.json, and SHA256SUMS for review. Those archives are not the public installation path.
Physical passkeys and the operator’s chosen HTTPS proxy need checks in that environment. Local virtual-authenticator and loopback proof must remain labeled accordingly. See the release verification checklist for the remaining evidence before publication.