Iterative study, knowledge audits and anti-drift checks¶
1. Iterative study plan (Claude, small slices, one per session)¶
Each slice reads one area and leaves one short note in docs/notes/. No slice runs if the weekly Claude quota is above 80%.
| # | Slice | Source | Output |
|---|---|---|---|
| S1 | C:\Projects register refresh |
Laptop, read only | Updated inventory; questions for unknown folders |
| S2 | WPDev live code: structure, features, API calls | Laptop folder after git fetch (pull only if clean, with Atul's OK) |
capabilities-wpdev.md |
| S3 | PE knowledge audit, step 1 (see §2) | PE git history: first design commits vs today | Concept list for Atul to tick |
| S4 | MCRM two-stream check (see §3) | MCRM docs 00–05 and plan | Stream map |
| S5 | API main vs stgapi branches: what stgapi adds |
GitLab API repo | capabilities-api.md |
| S6 | Staging website feature inventory (for MWMC's later milestone) | Staging repo | List of staging-only features |
Order: S1, S3, S4 first (risk), then S2, S5, S6.
2. Portfolio Engine knowledge audit¶
Concern (Atul, 14 Oct): PE started broad, became defensive, kept cutting scope, and is stuck at micro level. Atul is the only person who holds the full PE design.
Step 1 — concept list (Claude, one session). From PE's earliest design commits, architecture and product documents, list the concepts Atul taught PE (for example dynamic portfolios, business-rule construction, client review from CAS, ULIP and multi-product, configurable methodologies, the Gateway's two purposes). Atul ticks, corrects and adds (15 minutes).
Step 2 — retention check (Claude). For each concept, mark where it stands today: - Kept: in current design docs and reflected in code or the active plan. - Diluted: mentioned, but scope was cut or deferred without a recorded decision. - Lost: absent from current docs, instructions and plan.
Step 3 — blind test (PE agent). Ten questions that can be answered only if the knowledge survived ("What must PE do with a client's CAS?", "How are dynamic weights decided and audited?"). Answers come from the repository alone; Claude scores against Atul's ticked list.
Step 4 — recovery estimate. Small: one "PE design baseline" document restores it. Medium: baseline plus plan rework. Large: Atul's knowledge sessions needed. Result goes to Atul as one decision item.
3. MCRM: two parallel streams¶
MCRM is a collection of verticals; catalogue management is one of them.
- Stream I — immediate: catalogue for what production has today (MF, Health, Term, Motor, plus the category tree): WP1–WP3, feeding MWMC and API.
- Stream L — long term: the CRM verticals (Party/Identity/KYC, Dossier, Sales, Documents and Activities, Integration, partner and commission), Waves 0–6.
Rules: the plan shows both streams with their own milestones; every week has at least one visible Stream I increment; Stream L gets a fixed share (proposed: about one third of effort) and must not be dropped; MCRM keeps a short "destination" document current, as PE's handover does.
4. Anti-drift checks for every project (MMDEP, weekly)¶
Adapted from PE's own anti-drift list:
- Scope cuts need Atul. Reducing or deferring scope is a decision item, never a silent edit.
- Visible progress. Days since the last user-visible change; documents and evidence do not count alone.
- PR load. Open PRs above five, or a growing docs-only share, is flagged.
- Destination check. Each plan names its long-term destination and the next 2–3 visible capabilities; MMDEP compares month on month.
- Knowledge test. Each project answers a short blind test once a month; a drop is flagged to Atul.