Clarify roadmap and surface project banner

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
 

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.