Product Map

Product Map maintains a single canonical list of every user-facing feature, read straight from the code. It is product context rather than a discovery source: Watchdog uses it to choose journeys, and every Ranger plus Discovery Triage receives it to understand which part of the product a signal concerns.

How it stays current

After the connected repository's default branch changes, 1mn clones the repo read-only and reconciles the map. A weekly safety check catches missed webhooks or long-quiet repositories, and Sync now on Watchdog is the manual escape hatch. Unchanged commits are not rescanned.

For each distinct user-facing feature — a capability a user would actually feel or use, like "Google OAuth sign-in" or "AI visibility report", not internal plumbing — it records:

• A user story — who wants it and why.
• Expected behavior — what should happen when the feature is used. This becomes the oracle Story QA verifies against.
• A lifecycle status — live, partial, planned, or deprecated.

Because it reuses a stable key per feature, a re-scan updates rows in place instead of duplicating them: new features are added, changed ones updated, and ones that disappeared from the code are retired. The map lives under Watchdog → Product map.

What you get

• A reconciled list of every feature with its user story, expected behavior, lifecycle status, and source references.
• Watchdog priority controls: star important stories so they are tested first.
• A visible commit and last-synced time, so stale product context is obvious.

Notes & limits

• Product Map is read-only — it scans and records; it never changes code, creates a ticket, or opens a PR.
• It is not a Ranger and does not produce signals. It supplies context to Rangers and Triage.
• Browser verification belongs to Watchdog's Synthetic Browser Ranger; central Discovery Triage decides whether reproduced evidence becomes a draft Task.