diff --git a/README.md b/README.md index 2858f39..dfe02eb 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,7 @@ # Nitpick +![Nitpick workflow preview](docs/social-preview.svg) + [![CI](https://github.com/FlyLikeAPenguin/nitpick/actions/workflows/ci.yml/badge.svg)](https://github.com/FlyLikeAPenguin/nitpick/actions/workflows/ci.yml) [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE) [![Python 3.12+](https://img.shields.io/badge/python-3.12%2B-blue.svg)](https://www.python.org/) @@ -27,11 +29,7 @@ Before using Nitpick with production logs, review the data flow: matching log en ## Project status -Nitpick is an actively developed alpha project. The core pipeline, local dashboard, Datadog source, GitHub/Linear trackers, Markdown/Notion sinks, and console/Slack notifiers are implemented. See [issues](https://github.com/FlyLikeAPenguin/nitpick/issues) for current work and limitations. - -![Nitpick workflow preview](docs/social-preview.svg) - -See the [roadmap](docs/ROADMAP.md) for planned work and the [GitHub issues](https://github.com/FlyLikeAPenguin/nitpick/issues) for implementation-level tasks. +Nitpick is an actively developed alpha project. The core pipeline, local dashboard, Datadog source, GitHub/Linear trackers, Markdown/Notion sinks, and console/Slack notifiers are implemented. See the [roadmap](docs/ROADMAP.md) for the direction of the project and [issues](https://github.com/FlyLikeAPenguin/nitpick/issues) for implementation-level work. ## How it works diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 65785f6..8e12251 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -1,24 +1,76 @@ # Roadmap -The roadmap is intentionally short and outcome-focused. Priorities may change as users try Nitpick and report what blocks adoption. +Nitpick is moving toward a source-agnostic, reviewable incident-workflow layer: bring errors in from the systems a team already uses, investigate them with the agent backend it prefers, and send trustworthy findings to the places where work already happens. + +The roadmap is directional rather than a promise of dates. Adoption feedback, security, and operational reliability can change the order. Completed work is kept visible so the project’s progress is easy to assess. + +## Product direction + +```text +More log sources → one normalized incident model → more agent backends + ↓ + docs, issues, notifications, fix PRs + ↓ + local-first today → deployable tomorrow +``` + +The design principles stay constant as the surface area grows: + +- **Reviewable automation** — investigations explain their evidence; changes arrive as PRs. +- **Provider choice** — sources, agent backends, and sinks should be replaceable adapters. +- **Operational control** — budgets, permissions, retention, and approval gates remain visible. +- **Deploy anywhere** — start locally, then support dependable self-hosted operation. + +## Shipped in v0.1.0 + +- Datadog log ingestion with fingerprinting and SQLite deduplication. +- Claude CLI investigation with cost limits and structured RCA output. +- Markdown and Notion RCA sinks; GitHub and Linear issue trackers; console and Slack notifications. +- Optional fix PRs in isolated git worktrees, disabled by default. +- Local dashboard, credential-free demo mode, tests, CI, release packaging, and contributor/security guidance. ## Now -- Make the safe, reviewable workflow easy to install and understand. -- Improve test coverage around provider contracts, cache migrations, and error normalization. -- Document privacy, permissions, cost controls, and operational limitations. +The next focus is making the existing local workflow dependable enough for real teams: + +- Expand provider contract tests, cache migration coverage, and sanitized log fixtures. +- Improve dashboard accessibility, filtering, run history, and error-to-investigation navigation. +- Make privacy, retention, permissions, and cost behavior configurable and easy to audit. +- Improve setup and scheduling documentation for macOS, Linux, and repeatable upgrades. ## Next -- Add a fixture-backed demo mode that works without Datadog or Claude credentials. -- Add more error-source providers behind the existing provider interface. -- Improve dashboard accessibility and run history details. -- Add release automation and compatibility checks for supported Python versions. +### More sources + +- Add Sentry, OpenTelemetry/OTLP, and CloudWatch adapters behind the existing source interface. +- Support webhook and fixture inputs so teams can integrate systems without a bespoke polling loop. +- Preserve one normalized error model so downstream investigations do not depend on the source vendor. + +### More sinks and workflow integrations + +- Add Jira and additional issue/project-management adapters. +- Add richer incident destinations such as PagerDuty-style notifications and generic webhooks. +- Improve document output with linked timelines, evidence sections, and reusable RCA templates. + +### More agent backends + +- Add first-class Codex support alongside Claude CLI. +- Introduce a provider-neutral agent runner with explicit capability, permission, and cost contracts. +- Make model selection and investigation prompts configurable without coupling the pipeline to one vendor. + +### Deployability + +- Provide a documented Docker/Compose path for the pipeline and dashboard. +- Add production-oriented systemd and launchd examples with health checks and log rotation. +- Make database, logs, configuration, and secrets paths explicit so Nitpick can run cleanly in a container or worker host. ## Later -- Support richer incident timelines and related-error grouping. -- Add configurable approval gates before issue creation or fix-PR creation. -- Evaluate hosted or team-oriented deployment only after the local workflow is stable. +- Add richer incident timelines, related-error grouping, and cross-service correlation. +- Add approval gates before issue creation, external notifications, or fix-PR creation. +- Support a GitHub App integration so teams can minimize local CLI coupling and scope permissions precisely. +- Evaluate a hosted or multi-user deployment model only after self-hosted operation is stable and privacy boundaries are proven. + +## How priorities are chosen -Have a use case that should influence the order? [Open an issue](https://github.com/FlyLikeAPenguin/nitpick/issues/new/choose) with the problem and the desired outcome. +We prioritize work that reduces the time from a real error to a reviewed, well-documented action. Issues with sanitized examples, measurable user impact, and a clear privacy or operational model are especially useful. [Open an issue](https://github.com/FlyLikeAPenguin/nitpick/issues/new/choose) with the problem and desired outcome.