InnoDay is the hub every project reports to.

Development state scatters by default. The board knows what is planned, GitHub knows what shipped, the release tool knows the version, and the decisions from the last meeting live in someone's notes. Reconstructing “where is this project?” means stitching those together by hand, every time.

InnoDay's premise is that every significant event is recorded in one place, against one project. Skills, agents, and CLI tools all write back to it, so the history is always there to query. The rule of thumb: if you need to remember it across sessions or share it with the team, it belongs in InnoDay.

You don't self-host to use it. The common path is uv tool install innoday, then point the CLI at the shared, Railway-hosted environment. You only clone the repository to develop InnoDay itself.

The “record of truth” idea earns its keep by clearing six specific frustrations that show up on any multi-repo, multi-project software team.

InnoDay's data model is a strict hierarchy. An organization is the tenant and security boundary. Inside it, a project is the unit you actually work inside — and it is the join point that every other concept attaches to.

Why “project-centric” is more than a diagram: the database enforces it. A board can't exist without a project, a ticket can't exist without a project, and a release version is unique per project. There is no such thing as an org-only ticket floating outside a project.

The centerpiece

This is the part that makes InnoDay more than a tracker. Planning artifacts — tickets, boards, scope — live server-side. But the developer works in a folder full of repositories on their own machine. InnoDay closes that gap with one small file and one resolution rule.

The file: when you onboard a workspace, InnoDay writes a .innoday/project.yml into it. It records exactly which org and project this directory represents — by stable UUID, not just a name — plus the repos that belong to the project and the release state that blastoff owns.

# written by the workspace onboarder — schema v2
schema_version: 2
org:
  alias: hs
  name: Haviland Software
  innoday_id: 2e2ffce7-…      # org UUID — the source of truth
  github_org: havilandsoftware
project:
  alias: pf
  name: PixelFuel
  innoday_id: e52b7372-…      # project UUID
  github_topic: pixelfuel     # repos are discovered by this label
repos:
  - name: pixelfuel-blastoff
  - name: pixelfuel-website
release_configs:              # blastoff version state, preserved on refresh
  pf: { next_version: … , last_released_version: … }

The rule: every tool — the CLI, the MCP server, the release tool — walks up from wherever you are until it finds a .innoday/project.yml. It reads the org and project UUIDs out of that file and uses them for every API call. That's the whole trick: launching Claude Code or running innoday from inside a project folder “just works” with zero flags.

Because context is ambient, the daily loop is short. Everything below resolves the project automatically from the folder you're standing in:

# you are in ~/workspaces/hs/pf — org & project auto-resolve
$ innoday tickets list --status TODO
$ innoday tickets update --ticket-id <id> --status IN_PROGRESS
# …work in the repos project.yml lists, in a git worktree…
$ innoday sync            # pull board tickets + repo discovery + release state

The planning side (a ticket on a Linear board) and the doing side (a repo on your disk) are now two ends of the same thread — and the project.yml is the knot in the middle.

InnoDay ships as a Claude Code plugin as well as a CLI. The plugin bundles an MCP server and a set of agents that operate the platform on your behalf — all of them talking to the same REST API through the same cwd-resolved context.

Claude Code spawns the InnoDay MCP server locally (via uvx --from innoday mcp-server-innoday). It exposes the platform as 43 tools — create_ticket, sync_board, create_release, get_scrum_summary, and so on. Crucially, it holds no business logic: each tool is a thin HTTP call to the same REST API the CLI uses. Change a ticket by CLI or by agent — it's the same endpoint, the same record.

The Project Manager agent is the piece that makes “the board is the truth” sustainable: unattended, on a cadence, it does the tidying a human PM would otherwise do by hand — closing what's done, flagging what's drifted, and clearing what's orphaned.

InnoDay itself is a FastAPI service running on Railway, backed by Supabase Postgres. Everything a developer runs locally — the CLI, the MCP server, blastoff — is a client of that one deployed API.

Two deploy paths coexist right now — the platform is mid-migration from source builds to signed images.

The switch to the target path is a one-time manual step: repointing Railway's service source from the connected repo to the GHCR image. Railway pulls the public GHCR copy (not ECR) because that avoids the paid private-registry requirement; ECR remains the private, scan-on-push canonical copy, and Cosign signature verification — not secrecy — guarantees integrity.

For most people this is a five-minute install against the shared dev environment. You are configuring a client — you are not standing up a server.

# 1 · install the CLI (the MCP server ships in the same package)
$ uv tool install innoday

# 2 · initialize identity against the shared dev API
$ innoday init --default          # defaults to https://innoday-dev.up.railway.app
$ innoday orgs list               # verify the connection

# 3 · seed the team secret (the gotcha) — the dev API is gated; without a
#     matching X-Team-Secret header every non-public route returns 401
$ innoday config set team-secret "<the dev team secret>"

# 4 · onboard a workspace, then context resolves from the folder — no flags
$ cd ~/workspaces/hs/pf
$ innoday tickets list

If the CLI works but the MCP tools return 401, the MCP server cached the pre-seed config at startup — reconnect it (/mcp reconnect) so it re-reads the seeded config. A purely local API has no team secret.

That's the whole model: one project-shaped record in the cloud, a small file that binds a folder to it, and a handful of clients — CLI, MCP, blastoff — that all resolve the same context from wherever you happen to be working.