Handbook
Prompt 12A - Audit and preserve the existing Adaptive Feedback Framework domain
Run before Prompt 12.
Updated
Required context
- All AFF models, migrations, pack files, schedulers, selectors, APIs, jobs, and tests
- Supplied fixtures for packs, programs, windows, exposure ledger, lint, channels, and webhook deliveries
- The v0.1 adaptive framework Markdown pack
Prompt
Determine what AFF capability already exists, which invariants are implemented, and how to productize it without creating a parallel model.
1. Inventory the existing domain
Map existing code and storage for:
- construct, family, variant, scale, and relationship
- pack and pack version
- tenant overlay and tenant-owned content
- program and program version
- cadence and business calendar
- survey/window assembly
- anchor, rotating, mandatory, event, and PDP items
- bundles
- exposure ledger and cooldown
- deterministic seed and selection rationale
- coverage state and forecast
- mandatory overflow
- delivery channels and webhooks
- lint and publication workflow
For each concept record status: implemented, partial, fixture-only, absent, or conflicting.
2. Validate invariants with tests
Do not infer completeness from a fixture. Prove:
- deterministic assembly for the same version and seed
- shared exposure ledger across programs
- documented skip-period semantics
- daily/weekly/monthly/quarterly/yearly boundary behavior
- timezone, DST, leave, and business-calendar behavior
- atomic and splittable bundles
- feasible and infeasible full-coverage forecasts
- PDP force-next-once consumption and reversion
- tenant overlay versioning
- concurrency and idempotency
- anonymity and aggregate minimums
3. Establish migration and reuse rules
- Preserve stable identifiers that already have persisted history.
- Do not rename or fork existing packs merely to match UI wording.
- Version published content immutably.
- Define adapters where the current model differs from the target wiki.
- Backfill exposure/history only when source evidence exists.
4. Produce the Prompt 12 implementation plan
Split Prompt 12 into vertical slices:
- Read-only catalog and program inspection
- Pack/version governance
- Program builder
- Coverage and cooldown simulator
- Tenant overlays
- Publication and rollout
- Explainability and audit
Required outputs
wiki/internal/aff/existing-domain-map.md
wiki/internal/aff/invariant-test-matrix.md
wiki/internal/aff/gap-and-conflict-register.md
wiki/internal/aff/migration-and-reuse-plan.md
wiki/internal/aff/program-builder-slice-plan.md
Exit gate
Prompt 12 must not create new AFF tables or identifiers until the existing domain and migration impact are understood.