Note

    Project Compass Strategy

    High-level strategist logic for KPI-driven portfolio prioritization and drift detection.

    Source Summary

    --- title: Strategy description: What Portfolio Command (Project Compass) is trying to solve and the high-level "strategist" logic it uses to judge alignment and focus. status: evolving lastUpdated: "2026-02-13 07:23 ET (America/New_York)" owner: Product/Engineering --- # Strategy ## The Core Question Portfolio Command exists to answer: > What am I actually

    Imported Context

    title: Strategy description: What Portfolio Command (Project Compass) is trying to solve and the high-level "strategist" logic it uses to judge alignment and focus. status: evolving lastUpdated: "2026-02-13 07:23 ET (America/New_York)" owner: Product/Engineering

    Strategy

    The Core Question

    Portfolio Command exists to answer:

    What am I actually working on across all my projects, and is it the right stuff?

    "Right stuff" is defined by the user's strategic intent (KPIs/OKRs), not by activity volume.

    The Problem It Targets

    Across a multi-repo portfolio (side projects, OSS, freelance, internal tools), most engineers hit the same failure modes:

    • Work is fragmented. Evidence is split across GitHub activity, docs, and private notes.
    • Strategy drift is invisible. You can be "busy" while making no progress against what matters.
    • Health issues are detected too late. Stale PRs, runaway issue intake, and neglected repos accumulate quietly.
    • Manual portfolio management does not scale. Spreadsheets/Notion require constant upkeep and still do not interpret signal.

    Who It's For (and Not For)

    • Primary user: a solo engineer or small-team lead managing multiple repositories who wants a portfolio-level view with strategic alignment.
    • Non-goals (current):
      • Multi-tenant enterprise reporting.
      • Replacing a project manager or ticketing system.
      • Fully automated "always-on" monitoring (refresh is intentionally user-controlled today).

    Strategic Outcomes (What "Good" Looks Like)

    The product is successful when it:

    • Creates a single source of portfolio truth by unifying GitHub activity, repo docs, and user notes.
    • Extracts intent and goals from evidence, so goals represent what the work indicates (not what the user hopes is happening).
    • Measures focus and health in a way that is actionable, surfacing the specific levers a user can pull.
    • Closes the loop between strategy and execution by injecting the user's KPI framework into analysis, then evaluating progress against it.
    • Maintains trust through transparency (full prompt/response visibility, cost tracking, evidence references).

    "Strategist Logic" (High-Level Decision Rules)

    The system is built around a small set of strategy-first heuristics:

    1. Strategy must be explicit.

      • The user defines a KPI tree (Vision -> Objectives -> Key Results -> Tasks).
      • That hierarchy becomes the system's "north star" context for interpreting work.

    2. Evidence beats narrative.

      • Goals are synthesized from observed activity + documentation + notes.
      • Docs like CHANGELOG.md and ROADMAP.md are treated as high-signal for planned vs shipped work.

    3. Quality of progress beats quantity of activity.

      • "Lots of commits" does not necessarily mean "good focus."
      • Focus scoring penalizes common failure modes (scope creep, too many stale items) and rewards shipping discipline.

    4. Portfolio-level view matters more than repo-level optimization.

      • Cross-repo patterns (overcommitment, neglected projects, conflicting priorities) are treated as first-class signal.

    5. Trust requires auditability.

      • AI outputs must be explainable: evidence references, transparent scoring breakdown, and logs for every AI call in the ops pipeline.

    Key Constraints and Product Posture

    • BYOK (Bring Your Own Key): users bring OpenAI and/or Gemini keys.
    • Single-user optimized: UX and security defaults favor one owner account today, with guardrails that keep multi-user safe-by-default patterns possible.
    • Self-hostable: can run on local/hosted Supabase today; the target stack is migrating toward a standalone API + Neon.

    Where This Strategy Is Implemented

    • Product loop and feature intent: docs/features/FEATURES.md
    • Business framing: docs/features/LEAN_CANVAS.md
    • AI pipelines + scoring: docs/development/AI_COMPONENTS.md
    • End-to-end architecture: docs/development/ARCHITECTURE.md

    Provenance

    domain:builderdomain:entrepreneurstrategy