115 lines
4.1 KiB
Markdown
115 lines
4.1 KiB
Markdown
|
|
# Project Portfolio Workflow (2026-02-26)
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
Organize long-horizon projects into one execution system so Whetstone can either:
|
||
|
|
- finish existing MVPs from other machines/repos, or
|
||
|
|
- rebuild from scratch with deterministic quality gates.
|
||
|
|
|
||
|
|
## Current Inputs Found
|
||
|
|
- Whetstone core planning and sprint execution docs under `CLionProjects/whetstone_DSL/docs/`
|
||
|
|
- A project archive bundle under `drive_projects/drive-download-20260217T155135Z-1-001/` (mixed docs, requirements, roadmaps, MVP concepts)
|
||
|
|
- No literal `project_docs/` directory found under `/home/bill/Documents`
|
||
|
|
|
||
|
|
## Portfolio Lanes
|
||
|
|
1. `MVP_IMPORT`
|
||
|
|
- Existing codebase exists elsewhere (GitHub/private machine).
|
||
|
|
- Goal: ingest, normalize, and harden to production thresholds.
|
||
|
|
|
||
|
|
2. `GREENFIELD`
|
||
|
|
- No code to import or import is lower value than rebuild.
|
||
|
|
- Goal: generate from architecture + constraints and iterate with strict validation.
|
||
|
|
|
||
|
|
## Canonical Project Record (one row per project)
|
||
|
|
Use one table (or JSONL) with these required fields:
|
||
|
|
- `project_id`
|
||
|
|
- `name`
|
||
|
|
- `lane` (`MVP_IMPORT` or `GREENFIELD`)
|
||
|
|
- `source_of_truth` (repo URL / machine path / doc path)
|
||
|
|
- `problem_statement`
|
||
|
|
- `target_users`
|
||
|
|
- `critical_constraints` (latency, memory, security, platform)
|
||
|
|
- `status` (`intake`, `specifying`, `building`, `hardening`, `release_ready`, `paused`)
|
||
|
|
- `next_gate`
|
||
|
|
- `owner` (human/agent)
|
||
|
|
- `last_validated_at`
|
||
|
|
|
||
|
|
## Intake Gate (must pass before any build work)
|
||
|
|
1. Confirm the project has one primary source of truth.
|
||
|
|
2. Convert intent into a compact execution spec:
|
||
|
|
- target runtime/platform
|
||
|
|
- must-have features
|
||
|
|
- no-go constraints
|
||
|
|
- acceptance tests
|
||
|
|
3. Choose lane (`MVP_IMPORT` vs `GREENFIELD`) explicitly.
|
||
|
|
4. Create first 3-7 taskitems with deterministic completion checks.
|
||
|
|
|
||
|
|
## Lane Workflows
|
||
|
|
|
||
|
|
### A) MVP_IMPORT Workflow
|
||
|
|
1. `Snapshot`
|
||
|
|
- Pull/clone code and freeze baseline hash.
|
||
|
|
- Capture run/build/test state as-is.
|
||
|
|
|
||
|
|
2. `Normalize`
|
||
|
|
- Align repo layout, dependency pinning, and CI test entrypoints.
|
||
|
|
- Add missing schema/contract tests for core behavior.
|
||
|
|
|
||
|
|
3. `Gap Audit`
|
||
|
|
- Compare MVP behavior vs current intent docs.
|
||
|
|
- Tag each gap: `bug`, `missing feature`, `quality`, `security`, `scalability`.
|
||
|
|
|
||
|
|
4. `Hardening`
|
||
|
|
- Run strict taskitem pipeline on highest-risk gaps first.
|
||
|
|
- Require failing test first for each fix.
|
||
|
|
|
||
|
|
5. `Promotion`
|
||
|
|
- Promote only after acceptance suite and non-functional checks pass.
|
||
|
|
|
||
|
|
### B) GREENFIELD Workflow
|
||
|
|
1. `Architecture Freeze v0`
|
||
|
|
- Generate project skeleton + module contracts + acceptance tests.
|
||
|
|
|
||
|
|
2. `Execution Slices`
|
||
|
|
- Build in thin vertical slices with runnable tests every slice.
|
||
|
|
|
||
|
|
3. `Constraint Enforcement`
|
||
|
|
- Ensure projection/environment constraints are first-class in taskitems.
|
||
|
|
|
||
|
|
4. `Hardening`
|
||
|
|
- Reliability, determinism, performance, and security passes.
|
||
|
|
|
||
|
|
5. `Promotion`
|
||
|
|
- Same production gates as import lane.
|
||
|
|
|
||
|
|
## Readiness Score (0-5 each, promote at >= 20/25)
|
||
|
|
- `Spec Clarity`
|
||
|
|
- `Deterministic Test Coverage`
|
||
|
|
- `Operational Readiness` (build/release/runbook)
|
||
|
|
- `Security Posture`
|
||
|
|
- `Performance Budget Confidence`
|
||
|
|
|
||
|
|
## Weekly Cadence
|
||
|
|
1. Intake/triage (new or updated projects)
|
||
|
|
2. Lane assignment and top-3 portfolio priorities
|
||
|
|
3. Whetstone execution runs (taskitem batches)
|
||
|
|
4. Human review on blockers and lock-level decisions
|
||
|
|
5. Closeout: score update + next gate assignment
|
||
|
|
|
||
|
|
## Suggested Immediate Backlog
|
||
|
|
1. Create `project_registry.jsonl` in Whetstone docs/data.
|
||
|
|
2. Import project list from your planning docs (especially the drive archive and any external repos).
|
||
|
|
3. For each project, set lane and next gate.
|
||
|
|
4. Start with 3 projects only:
|
||
|
|
- one `MVP_IMPORT` with highest near-term value
|
||
|
|
- one `GREENFIELD` infrastructure library
|
||
|
|
- one `GREENFIELD` demonstrator product
|
||
|
|
5. Run strict taskitem generation for those 3 and calibrate thresholds before scaling portfolio width.
|
||
|
|
|
||
|
|
## Notes From Existing Whetstone State
|
||
|
|
- You already have mature sprint/taskitem infrastructure and closeout artifacts.
|
||
|
|
- Active gap logs indicate the main risk now is execution quality drift, not idea scarcity.
|
||
|
|
- Portfolio organization should therefore optimize for:
|
||
|
|
- deterministic closeout quality
|
||
|
|
- clear source-of-truth linkage
|
||
|
|
- controlled concurrent project count
|