innoday 0.1.54b0

AI-Powered Team Orchestration Platform - Streamline product development and team collaboration with AI

InnoDay Platform

InnoDay is the central hub of your project. Every significant event — ticket work, releases, spec changes, board syncs, repo additions, meeting decisions — is recorded here. Skills, agents, and CLI tools all write back to InnoDay so the full history of a project is always queryable in one place.

AI-powered development platform for managing tickets, boards, repositories, and releases with Claude AI integration.

📖 New here?

• Just getting connected? → Quickstart (install → log in → onboard a workspace, ~5 min)
• Want to understand how it works? → Platform Guide — a visual, diagram-driven walk-through of the project-centric model, the planning→development bridge, the agents, and the deployment topology. Interactive branded version: How InnoDay Works.

What it solves

Development state scatters across a board, GitHub, a release tool, and someone's meeting notes. InnoDay pulls it into one project-shaped record — so tickets, board activity, timelines, AI-generated summaries, cross-repo releases, and team visibility all live in one queryable place, and an AI teammate stays productive across sessions instead of being re-briefed each time.

The full treatment — the six problems it solves, with before/after for each — is in the Platform Guide § "Six problems it solves".

🚀 Quick Start

Most people just need the CLI, pointed at the shared dev environment — not a repo clone or a self-hosted platform.

uv tool install innoday          # install the CLI from PyPI
innoday login --with-token       # paste your innoday_… token when prompted
innoday init hs/pf               # onboard a project workspace (clones + configures repos)
innoday status                   # verify: identity, resolved project, token, API health

Full walkthrough — including token handling, working across projects, and the "already used InnoDay before?" upgrade step — is in docs/QUICKSTART.md.

Only clone this repo and run a platform yourself if you're standing up your own instance (self-hosting, or local development on InnoDay itself) — see Running Your Own Platform below.

🤖 Claude Code MCP Integration

Add InnoDay directly to Claude Code — create tickets, sync boards, and query work items without leaving your editor. Reuses the CLI config from the Quick Start above.

claude mcp add innoday -- uvx --from innoday mcp-server-innoday

Or find it in the MCP registry: io.github.havilandsoftware/mcp-server-innoday.

Prefer the full plugin? Installing InnoDay as a Claude Code plugin bundles the MCP server plus the InnoDay agents and skills in one step — no separate claude mcp add:

/plugin marketplace add havilandsoftware/innoday
/plugin install innoday@innoday

The MCP Integration Guide is the canonical reference — the full tool catalog, environment variables (INNODAY_API_URL, INNODAY_TEAM_SECRET), how org/project context resolves from .innoday/project.yml, and troubleshooting. (This README deliberately doesn't maintain a second hand-written tool list, to avoid the two drifting apart.)

Stale MCP tools after a fix ships? If mcp__innoday__* calls keep failing the same way after a fix has merged and published, the installed binary is stale — claude mcp add/reconnect doesn't re-fetch code. Fix: uv tool upgrade innoday --reinstall (the --reinstall bypasses uv's version pin), then /mcp reconnect. Full root-cause explanation in docs/VERSION_MANAGEMENT.md ("Reset history").

🗂️ Config & Project Setup

Two files at two scopes — keep them straight:

File	Scope	What it holds
~/.innoday/config.json	Your machine, all projects	Identity: profile, API URL, your user id, team secret, a cached org map. Never stores integration secrets — only pointers (system keyring / Supabase Vault). The current org/project is never persisted here.
<workspace>/.innoday/project.yml	One project workspace	Which org + project this directory is, plus the repos that make it up. Written by innoday init / innoday refresh.

Context is resolved from your current directory: every tool (CLI, MCP server, blastoff) walks up from where you are until it finds a .innoday/project.yml, and uses the org/project in it — so running from inside a workspace "just works" with zero flags. There is no persistent "switch" command; a --organization/--project flag overrides for one call only.

The object model (Organization → Project → Board/Ticket/Repository/Release) and the exact resolution precedence are explained in full in the Platform Guide § "The project-centric model" and PROJECT_ARCHITECTURE.md.

📇 CLI Reference

The everyday commands — run innoday <command> --help for the full flag list on any of them:

# Onboarding (see docs/QUICKSTART.md)
innoday login --with-token        # authenticate (or plain `innoday login` for browser device flow)
innoday init <org>/<proj>         # onboard a project workspace by alias, e.g. hs/pf
innoday refresh                   # re-pull repos + rebuild context for the current workspace
innoday whoami                    # show the logged-in identity
innoday status                    # connectivity, identity, orgs, assigned tickets

# Everyday work (context auto-resolves from cwd's .innoday/project.yml)
innoday tickets list                                   # list tickets
innoday tickets create "New feature"
innoday tickets update --ticket-id <id> --status IN_PROGRESS
innoday sync                                           # cascade: board tickets + repo discovery + release state
innoday orgs list                                      # organizations you can access

The CLI Documentation has the exhaustive command catalog (projects, boards, scope, repo discovery, service management, output formats). Self-hosting a platform locally uses the innoday platform … commands — see Running Your Own Platform.

🔧 Running Your Own Platform

Only needed if you're self-hosting InnoDay or developing on this repo itself — most users want the Quick Start above instead.

git clone [e-mail]:havilandsoftware/innoday.git
cd innoday
./install.sh
innoday platform init   # Interactive setup wizard (new terminal)

The full walkthrough — prerequisites, database setup, environment variables, verification, platform staff roles, known limitations — is the canonical docs/PLATFORM_SETUP.md; this README doesn't duplicate it.

Other ways to run it:

No installation — run from the cloned repo directly

git clone https://github.com/havilandsoftware/innoday.git
cd innoday
./bin/innoday --version   # Wrapper: cd's to repo root, runs via uv, no install step

cat > .env.local <<'EOF'
ENVIRONMENT=local
DATABASE_URL=postgresql://innoday:innoday_pass@localhost:54322/innoday
CLAUDE_API_KEY=your-claude-api-key
GITHUB_TOKEN=your-github-token
GITHUB_ORG=havilandsoftware
EOF

./bin/innoday platform start --env local

Docker Compose

git clone https://github.com/havilandsoftware/innoday.git
cd innoday
docker compose up -d

Service URLs (local): REST API http://localhost:8002 (docs) · Agent API http://localhost:9000 · Web UI http://localhost:7860

✨ Key Features

• AI team orchestration — smart update collection, SCRUM facilitation, workload distribution, and Claude-powered conversation analysis.
• Central hub / record of truth — tickets, releases, board syncs, scope changes, repo additions, and agent output all write back to InnoDay. Rule of thumb: if you need to remember it across sessions or share it, save it here — local .innoday/memory.json is only a cache.
• Project-based organization — goals, versioned scope docs, repository layer classification, and one board per project (enforced at the DB level).
• Unified multi-platform integration — Jira, Trello, Notion, Linear, and GitHub behind one universal ticket model, with token pass-through (credentials never stored in the DB).
• Enterprise-ready — org-based multi-tenancy, RBAC (MEMBER/ADMIN/OWNER/DEVELOPER/PLATFORM), and usage-based license tiers.

The full narrative — with diagrams and the enforced-hierarchy rationale — is in the Platform Guide.

📖 Documentation

• Quickstart — Get connected in ~5 minutes: install the CLI, log in, onboard a workspace. Branded browser version: docs/html/quickstart.html.
• Platform Guide — Concepts: how InnoDay works (the project-centric model, planning→dev bridge, agents, infrastructure). Interactive version: How InnoDay Works.
• Platform Setup Guide — Full self-hosting walkthrough: prerequisites, database, environment variables, verification.
• Setup Guide: Organizations & Projects — Create an org, connect boards/repos, and configure projects.
• MCP Integration Guide — Connect InnoDay to Claude Code via MCP; the canonical tool reference.
• CLI Documentation — Command-line interface guide.
• API v1 Workflows · REST API Reference — API recipes and the full endpoint reference.
• Project Architecture · Domain Model — The project-centric model and core business objects.
• Contributing Guide — Development setup, tests, code style, and contribution workflow.
• Version Management — Release and versioning process.
• Changelog — Version history.

🧪 Development

Contributor setup, the full test suite, and code-quality tooling (black / isort / flake8 / mypy) live in CONTRIBUTING.md. The short version:

uv sync && uv run alembic upgrade head        # deps + migrations
ENVIRONMENT=local uv run python -m pytest tests/ -v   # tests
uv run black . && uv run isort .              # format

🏗️ Architecture

A modular FastAPI service (src/api, src/routers, src/services, src/domain, src/cli, src/agent, src/ui) backed by SQLModel/Postgres, with a Gradio UI and a Rich-powered CLI. All operations are organization-scoped under /api/v1/organizations/{org_id}/…, with a special protected Platform Organization for system administration.

The design and the full domain/endpoint layout are documented in PROJECT_ARCHITECTURE.md, API_V1_WORKFLOWS.md, and ARCHITECTURE_ORGANIZATION_CENTRIC.md.

🚢 CI/CD & Deployment

Every merge to main auto-bumps the patch version, publishes the package to PyPI and the MCP registry, and creates a GitHub release. See docs/VERSION_MANAGEMENT.md for the release mechanism and CLAUDE.md for deployment (Railway) details.

🤝 Contributing

Fork → feature branch → PR. Full development standards and the contribution workflow are in CONTRIBUTING.md.

📞 Support

• Issues: GitHub Issues
• Email: [e-mail]
• Enterprise: Contact for custom deployments and integrations

📄 License

This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0) — see the LICENSE file for details.

---

Built with ❤️ by Haviland Software