mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/dmux-workflows/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: dmux-workflows
+version: 1.0.0
+min_mindforge_version: 10.0.5
+status: stable
+triggers: dmux, parallel agents, multi-model orchestration, tmux agents, worktree parallel, parallel panes, concurrent execution, multi-harness, orchestrate workers, split work, fan out, parallel branches
+---
+
+# Skill — Dmux Workflows (Multi-Agent Parallel Execution)
+
+## When this skill activates
+
+When executing multiple independent tasks simultaneously using parallel agent
+instances, tmux panes, or git worktrees. Use when facing 2+ tasks that have no
+shared state, no sequential dependencies, and would benefit from concurrent
+execution. Handles isolation, coordination, and merge strategies for parallel work.
+
+Core principle: **Independence before parallelism** — never parallelize tasks that
+touch the same files or depend on each other's output.
+
+## Mandatory actions when this skill is active
+
+### Before parallel execution begins
+
+1. **Task decomposition:**
+   - List all subtasks in the current work item
+   - For each pair of subtasks, verify: do they touch the same files? (NO required)
+   - For each pair, verify: does one depend on the other's output? (NO required)
+   - If ANY dependency exists: serialize those tasks, parallelize the rest
+
+2. **Worker definition:**
+   ```json
+   {
+     "session": "dmux-[feature-name]",
+     "workers": [
+       {
+         "name": "worker-1-description",
+         "task": "specific task instructions",
+         "model": "sonnet|opus|haiku",
+         "branch": "feat/[feature]-[subtask]",
+         "files": ["list", "of", "files", "this", "worker", "touches"],
+         "timeout_minutes": 30
+       }
+     ]
+   }
+   ```
+
+3. **Independence verification matrix:**
+   - Create file-touch matrix: workers (rows) x files (columns)
+   - If any column has more than one worker marked: STOP, restructure tasks
+   - This is the critical safety check — skip it and you get merge conflicts
+
+4. **Select execution pattern:**
+
+   | Pattern | Workers | Use when |
+   |---------|---------|----------|
+   | Research + Implement | 2 | One explores options, other builds after |
+   | Multi-file | 2-4 | Each worker owns distinct files |
+   | Test + Fix | 2 | Watcher finds bugs, fixer resolves them |
+   | Cross-model review | 3 | Security + perf + coverage perspectives |
+   | Fan-out gather | 3-5 | Same prompt, different models, best-of-N |
+
+### During parallel execution
+
+**Launch protocol:**
+1. Create tmux session: `tmux new-session -d -s dmux-[name]`
+2. For each worker beyond the first: `tmux split-window` or `tmux new-window`
+3. Set up git worktree for each pane:
+   ```bash
+   git worktree add ../worktree-[worker-name] -b [worker-branch]
+   ```
+4. Launch agent in each pane with task-specific instructions
+5. Maximum 5-6 panes (beyond this, coordination overhead exceeds benefit)
+
+**Isolation guarantees:**
+- Each worker operates in its own worktree (filesystem isolation)
+- Each worker has its own branch (git isolation)
+- No worker reads files that another worker writes
+- Workers do NOT communicate during execution (no shared state)
+
+**Monitoring during execution:**
+- Check pane output periodically for errors or stalls
+- If a worker finishes early: do NOT reassign it (avoid introducing dependencies)
+- If a worker fails: note the failure, continue others, address in merge phase
+- Track wall-clock time per worker for future estimation
+
+**Resource constraints:**
+- Max 5-6 concurrent panes (token budget and context limits)
+- Each worker should complete within its timeout
+- If total token usage exceeds budget: kill lowest-priority worker first
+- Prefer fewer workers with clear tasks over many workers with vague tasks
+
+### After parallel execution
+
+1. **Merge strategy (sequential, NOT parallel):**
+   - Review each worker's output independently
+   - Verify each worker stayed within its file boundaries
+   - Merge workers one at a time into the integration branch:
+     ```bash
+     git checkout main-feature-branch
+     git merge worktree-[worker-1-branch] --no-ff
+     # verify tests pass
+     git merge worktree-[worker-2-branch] --no-ff
+     # verify tests pass
+     # repeat for each worker
+     ```
+   - Run full test suite after all merges
+
+2. **Conflict resolution:**
+   - If merge conflict occurs: investigate which worker violated boundaries
+   - Resolve manually (do not auto-resolve — understand the conflict)
+   - Add the conflicting files to a "shared files" list for future runs
+
+3. **Cleanup:**
+   - Remove all worktrees: `git worktree remove ../worktree-[name]`
+   - Delete worker branches if fully merged
+   - Close tmux session: `tmux kill-session -t dmux-[name]`
+   - Consolidate results into a single summary
+
+4. **Results consolidation:**
+   ```
+   ## Dmux Execution Report
+   - Session: dmux-[name]
+   - Workers: N launched, M succeeded, F failed
+   - Wall-clock time: X minutes (vs estimated Y sequential)
+   - Speedup factor: sequential_time / parallel_time
+   - Conflicts: [none | list with resolution]
+   - Output: [summary of what each worker produced]
+   ```
+
+## Self-check before task completion
+
+Before marking a parallel execution task done:
+
+- [ ] Did I verify task independence (no shared files, no output dependencies)?
+- [ ] Did I use git worktrees for filesystem isolation?
+- [ ] Did I stay within the 5-6 pane maximum?
+- [ ] Did I review each worker's output independently before merging?
+- [ ] Did I run full tests after all merges completed?
+- [ ] Did I clean up worktrees and close the tmux session?
+- [ ] Did I document the speedup factor and any conflicts encountered?

package/.mindforge/skills/dns-architecture/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: dns-architecture
+version: 1.0.0
+min_mindforge_version: 10.1.1
+status: stable
+triggers: dns architecture, dns load balancing, dns failover, GeoDNS, TTL strategy, dns service discovery, dns-based routing, dns health check, dns propagation, anycast dns, dns caching layer, dns resolution chain
+---
+
+# Skill — DNS Architecture
+
+## When this skill activates
+Any task involving DNS-based traffic management, load balancing via DNS,
+failover strategies, GeoDNS routing, service discovery using DNS,
+or TTL optimization for high-availability systems.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Map the DNS resolution chain (client → resolver → authoritative → response).
+2. Identify failover requirements (RTO target determines TTL).
+3. Decide routing strategy (round-robin, weighted, latency, geo, failover).
+4. Determine health check mechanism for DNS-managed endpoints.
+
+### During implementation
+- Set TTL appropriate to failover speed requirements.
+- Implement health checks for all DNS-managed endpoints.
+- Use anycast for latency-critical global services.
+- Configure both primary and secondary DNS providers for resilience.
+- Document propagation delays for operational runbooks.
+- Never rely on DNS as sole load balancer for sub-second failover.
+
+### After implementation
+- Verify health checks remove unhealthy endpoints within TTL window.
+- Test failover scenario end-to-end (kill primary, measure recovery time).
+- Confirm GeoDNS routes correctly from each target region.
+- Monitor DNS resolution latency and error rates.
+- Validate TTL behavior in major resolvers (Google, Cloudflare, ISP).
+
+## DNS Load Balancing
+
+### Strategies
+| Strategy | How It Works | Best For |
+|----------|-------------|----------|
+| Round-robin | Rotate through A records | Simple distribution |
+| Weighted | Assign weight per endpoint | Canary, capacity differences |
+| Latency-based | Route to lowest-latency endpoint | Global services |
+| Failover | Primary/secondary with health check | HA with clear primary |
+| Geo | Route by resolver geography | Data sovereignty, latency |
+
+### Limitations
+- DNS caching means changes take TTL seconds to propagate.
+- Client-side caching may ignore TTL (some browsers cache 60s minimum).
+- Cannot do sub-second failover via DNS alone.
+- Resolver location != user location (use EDNS Client Subnet to improve).
+
+## GeoDNS
+
+### How It Works
+1. DNS query arrives at authoritative server.
+2. Server determines resolver's geographic location (via IP geolocation).
+3. Returns IP address of nearest datacenter.
+4. EDNS Client Subnet (ECS) improves accuracy by passing client subnet.
+
+### Configuration
+```
+# Example GeoDNS policy
+api.example.com:
+  default: us-east-1.api.example.com
+  EU: eu-west-1.api.example.com
+  APAC: ap-southeast-1.api.example.com
+  fallback: us-east-1.api.example.com  # if region unhealthy
+```
+
+### Considerations
+- Resolver location != user location (corporate DNS, VPN users).
+- ECS support improves accuracy but not universally supported.
+- Always have fallback for unresolvable regions.
+- Test from each target region to verify correct routing.
+
+## TTL Strategy
+
+### TTL Decision Framework
+| Scenario | Recommended TTL | Reason |
+|----------|----------------|--------|
+| Fast failover needed | 30-60 seconds | Quick removal of unhealthy |
+| Normal operation | 300 seconds (5 min) | Balance between freshness and cache |
+| Static content CDN | 3600 seconds (1 hour) | Rarely changes, maximize cache |
+| During migration | 60 seconds | Prepare for cutover |
+| After migration stable | 300-3600 seconds | Return to normal caching |
+
+### TTL Trade-offs
+- **Low TTL (30s)**: Fast failover, more DNS queries, higher authoritative load.
+- **High TTL (3600s)**: Fewer queries, better cache hit rate, slow failover.
+- **Strategy**: Lower TTL before planned changes, raise after stability confirmed.
+
+### Propagation Reality
+- TTL expiry != instant propagation.
+- Some resolvers enforce minimum TTL (30s-60s).
+- Browser DNS cache may ignore TTL entirely.
+- Java apps cache DNS indefinitely by default (set `networkaddress.cache.ttl`).
+
+## Service Discovery via DNS
+
+### Internal Service Discovery
+- Use internal DNS zone (e.g., `service.internal`).
+- SRV records provide port discovery alongside host.
+- Short TTL (5-15s) for dynamic service registration.
+
+### SRV Records
+```
+_http._tcp.api.internal. 15 IN SRV 10 100 8080 api-pod-1.internal.
+_http._tcp.api.internal. 15 IN SRV 10 100 8080 api-pod-2.internal.
+```
+
+### Kubernetes DNS
+- Service discovery built-in: `service-name.namespace.svc.cluster.local`.
+- Headless services return individual pod IPs.
+- ExternalName services alias external endpoints.
+
+## Anycast DNS
+
+### How It Works
+- Multiple servers advertise the same IP address via BGP.
+- Network routes traffic to the nearest server (by BGP path).
+- If one server goes down, BGP re-routes to next nearest.
+
+### Use Cases
+- Authoritative DNS servers (Cloudflare, Route53).
+- CDN edge nodes.
+- DDoS mitigation (absorb attack across multiple PoPs).
+
+### Considerations
+- Failover speed depends on BGP convergence (seconds to minutes).
+- TCP connections break on route change (DNS is UDP, so usually fine).
+- Not suitable for stateful protocols without session persistence.
+
+## Health Checks
+
+### DNS Health Check Pattern
+1. Health checker probes endpoints at regular intervals (10-30s).
+2. If endpoint fails N consecutive checks, remove from DNS response.
+3. Continue probing. If endpoint recovers, add back after M consecutive successes.
+4. Removal takes effect within TTL seconds (resolver cache expiry).
+
+### Health Check Types
+| Type | Checks | Use For |
+|------|--------|---------|
+| TCP | Port open | Basic availability |
+| HTTP | Status 200 + body match | Application health |
+| HTTPS | Valid cert + status | Full stack health |
+| Custom | Business logic probe | Application-specific |
+
+### Timing
+- Check interval: 10-30 seconds.
+- Failure threshold: 2-3 consecutive failures.
+- Recovery threshold: 2-3 consecutive successes.
+- Effective failover time: check_interval × failure_threshold + TTL.
+
+## Self-check
+- [ ] TTL set appropriate to failover speed requirement.
+- [ ] Health checks configured for all DNS-managed endpoints.
+- [ ] Failover tested end-to-end (measured recovery time).
+- [ ] GeoDNS verified from target regions.
+- [ ] Secondary DNS provider configured for resilience.
+- [ ] Propagation delays documented in runbook.
+- [ ] Client-side DNS caching behavior accounted for.
+- [ ] Monitoring in place for resolution latency and errors.

package/.mindforge/skills/doc-health-audit/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: doc-health-audit
+version: 1.0.0
+min_mindforge_version: 10.0.3
+status: stable
+triggers: documentation audit, doc health, stale docs, outdated documentation, README outdated, doc maintenance, documentation drift, claim validation, doc review, doc coverage, broken links
+compose:
+  - documentation
+---
+
+# Skill — Documentation Health Audit
+
+## When this skill activates
+When reviewing documentation quality, checking for staleness, validating
+code references in docs, or performing periodic maintenance on project documentation.
+
+## Mandatory actions when this skill is active
+
+### Before auditing
+1. Identify all documentation files in the project (README, docs/, CHANGELOG, API docs, etc.)
+2. Note the last modification date of each doc file
+3. Note recent code changes that SHOULD have triggered doc updates
+
+### The 5-Point Health Check
+
+**1. Claim Validation**
+For every factual claim in docs (code examples, API signatures, file paths):
+- Verify the referenced code/file ACTUALLY EXISTS
+- Verify code examples COMPILE and RUN correctly
+- Verify API signatures match current implementation
+- Flag any claim that cannot be verified as "UNVERIFIED"
+
+**2. Staleness Detection**
+A doc is STALE if:
+- Code it references has changed since the doc was last updated
+- More than 20 commits have touched referenced files without doc update
+- It references deprecated APIs, removed features, or old patterns
+- Version numbers or counts are outdated
+
+**3. Coverage Gaps**
+Check for undocumented areas:
+- Public APIs without usage examples
+- Features without user-facing documentation
+- Error codes without explanation
+- Configuration options without description
+- New files/modules without architectural context
+
+**4. Consistency Check**
+Across all docs, verify:
+- Version numbers are consistent (README vs package.json vs CHANGELOG)
+- Naming is consistent (same feature called the same thing everywhere)
+- Instructions don't contradict each other
+- Links between docs are not broken (internal cross-references)
+
+**5. Maintenance Scoring**
+Score each doc file 0-10:
+- 9-10: Current, accurate, comprehensive
+- 6-8: Minor issues (outdated example, missing edge case)
+- 3-5: Significant staleness (multiple outdated references)
+- 0-2: Dangerously outdated (actively misleading)
+
+### Output Format
+
+Write to `.planning/DOC-HEALTH-REPORT-[timestamp].md`:
+```markdown
+# Documentation Health Report
+Date: [timestamp]
+Files audited: [count]
+Overall score: [average across all files]
+
+## Critical Findings (score 0-2)
+| File | Issue | Impact |
+...
+
+## Stale Docs (score 3-5)
+| File | Last Updated | Code Changes Since | Top Issue |
+...
+
+## Healthy Docs (score 6+)
+| File | Score | Minor Issues |
+...
+
+## Coverage Gaps
+- [undocumented area 1]
+- [undocumented area 2]
+
+## Recommendations (prioritized)
+1. [highest impact fix]
+2. ...
+```
+
+### After audit
+- Create action items for all Critical findings (score 0-2)
+- Suggest specific fixes for Stale docs
+- Log audit summary in AUDIT
+- Consider: should any finding become an instinct? (e.g., "always update README when adding new commands")
+
+## Self-check before task completion
+- [ ] Did I verify code references in docs actually exist?
+- [ ] Did I check code examples compile/run correctly?
+- [ ] Did I produce a DOC-HEALTH-REPORT with per-file scores?
+- [ ] Did I create action items for any Critical findings (score 0-2)?

package/.mindforge/skills/ecommerce-architecture/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: ecommerce-architecture
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: ecommerce architecture, shopping cart design, checkout flow optimization, inventory management system, pricing engine, order lifecycle management, marketplace architecture, product catalog design, ecommerce platform, fulfillment system, order routing, dynamic pricing
+compose: caching-strategies
+---
+
+# Skill — Ecommerce Architecture
+
+## When this skill activates
+This skill activates when designing shopping cart flows, checkout experiences, inventory management systems, pricing engines, order lifecycle workflows, product catalog architectures, marketplace platforms, or fulfillment/logistics systems for ecommerce.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design cart and checkout state machine: anonymous cart → logged-in cart (merge/replace strategy), cart → checkout (address validation), checkout → payment → order confirmation, with explicit timeout handling for abandoned carts (30 min session, 7 day recovery email)
+2. Model inventory architecture: real-time available-to-promise (ATP) calculation across warehouses, reserved inventory during checkout (soft hold 15 min, hard hold at payment), backorder handling, and oversell prevention with pessimistic locking
+3. Map order lifecycle stages: order placed → payment authorized → fraud screening → fulfillment assigned → picked → packed → shipped → delivered → returns window, with event-driven state transitions and webhook notifications at each stage
+
+### During implementation
+- Implement cart persistence with multi-device sync: store cart in database (not just sessions), deduplicate items by SKU+options hash, handle quantity updates with stock validation, expire abandoned carts after 30 days, support guest cart migration to user account on login
+- Build pricing engine with rule evaluation: base price → promotional discounts (BOGO, percentage off, fixed amount) → coupon codes (stackable/non-stackable) → volume discounts → tax calculation (Avalara/TaxJar API), with price display consistency (cart/checkout/confirmation must match)
+- Design inventory reservation system: when checkout starts, create soft reservation (pessimistic lock), release on timeout or explicit cancel, convert to hard reservation on payment success, allocate to specific warehouse based on proximity to shipping address and stock availability
+- Implement order routing logic: evaluate fulfillment options (ship from warehouse, dropship from vendor, ship from store), calculate shipping cost and delivery ETA per option, optimize for cost vs speed vs carbon footprint, handle split shipments when inventory spans locations
+- Build product catalog with faceted search: index products in Elasticsearch/Algolia with attributes (category, brand, color, size, price), support filters (multi-select facets), range queries (price slider), text search with typo tolerance, and sort options (relevance, price, rating, recency)
+
+### After implementation
+- Validate checkout flow conversion: measure cart abandonment rate by stage (cart → checkout → payment → confirmation), identify friction points (shipping cost surprise, account creation forced, payment failure), implement address autocomplete (Google Places API), express checkout options (Apple Pay, Shop Pay)
+- Test inventory consistency under load: simulate concurrent purchases of last item in stock (race condition), verify oversell prevention, validate soft reservation expiry releases inventory back to available pool, confirm hard reservation deducts from ATP correctly
+- Execute fraud screening integration: verify address verification system (AVS) checks, CVV validation, velocity checks (too many orders from same IP/card), device fingerprinting (Sift/Forter), manual review queue for high-risk orders
+
+## Self-check before task completion
+- [ ] Cart supports guest and logged-in users, syncs across devices, handles item updates with real-time stock validation
+- [ ] Pricing engine evaluates all discount layers (promotions → coupons → volume → tax) with consistent display across cart/checkout/confirmation
+- [ ] Inventory reservation implemented: soft hold during checkout (15 min timeout), hard hold post-payment, pessimistic locking prevents oversell
+- [ ] Checkout flow optimized: address autocomplete, saved payment methods, express checkout options (Apple Pay), progress indicator
+- [ ] Order lifecycle event-driven: state machine with webhook notifications (order placed, shipped, delivered), customer email templates
+- [ ] Product catalog searchable: faceted filters, text search with typo tolerance, sort options, pagination or infinite scroll
+- [ ] Fraud screening integrated: AVS/CVV checks, velocity limits, device fingerprinting, manual review queue for high-risk transactions

package/.mindforge/skills/edge-computing/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: edge-computing
+version: 1.0.0
+min_mindforge_version: 10.1.1
+status: stable
+triggers: edge computing, edge function, CDN compute, edge worker, latency optimization, data locality, edge caching, cloudflare workers, deno deploy, edge runtime, compute at edge, edge-first architecture
+---
+
+# Skill — Edge Computing
+
+## When this skill activates
+Any task involving moving computation closer to users at the network edge,
+designing edge functions, optimizing latency through geographic distribution,
+or evaluating edge vs origin placement decisions.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify latency-sensitive paths that benefit from edge execution.
+2. Decide edge vs origin for each operation using the decision matrix:
+   - Latency-sensitive reads → edge
+   - Data-heavy computation → origin
+   - Personalization with small state → edge
+   - Writes requiring strong consistency → origin
+3. Document runtime constraints (time limits, memory, bundle size).
+
+### During implementation
+- Keep edge function bundles small (<1MB) to minimize cold starts.
+- Avoid heavy imports — each dependency adds cold start latency.
+- Use stale-while-revalidate for cache coordination.
+- Handle edge-to-origin fallback gracefully.
+- Never rely on persistent connections at edge (stateless by design).
+- Implement proper cache-control headers at every layer.
+
+### After implementation
+- Measure actual latency improvement from edge deployment.
+- Verify data locality compliance (GDPR region constraints).
+- Test cold start performance under real traffic patterns.
+- Monitor edge function error rates per region.
+
+## Edge vs Origin Decision Framework
+
+| Signal | Edge | Origin |
+|--------|------|--------|
+| Latency-critical (<50ms target) | Yes | No |
+| Heavy computation (>50ms CPU) | No | Yes |
+| Personalization (small state) | Yes | No |
+| Database writes | No | Yes |
+| Static asset serving | Yes | No |
+| Auth token validation | Yes | No |
+| Complex business logic | No | Yes |
+
+## Platform Patterns
+
+### Cloudflare Workers
+- V8 isolate model (no container cold start).
+- KV for eventual-consistent edge state.
+- Durable Objects for strong consistency at edge.
+- R2 for edge-local object storage.
+
+### Vercel Edge Functions
+- Runs on Cloudflare infrastructure.
+- Streaming responses supported.
+- Middleware pattern for auth/redirects.
+
+### Deno Deploy
+- Global V8 isolates with zero cold start.
+- Built-in KV for edge state.
+- Native Web APIs (fetch, streams, crypto).
+
+## Caching Strategy at Edge
+- `Cache-Control: public, max-age=60, stale-while-revalidate=300` for dynamic content.
+- `Cache-Control: public, max-age=31536000, immutable` for hashed static assets.
+- Purge on deploy for cache invalidation.
+- Use cache tags for granular invalidation.
+
+## Limitations to Always Consider
+- Time limits (typically 30s-50ms CPU time depending on platform).
+- Memory limits (128MB typical).
+- No persistent connections (WebSocket requires special handling).
+- Bundle size constraints (1-10MB depending on platform).
+- Limited Node.js API compatibility at edge.
+- Eventual consistency for distributed edge state.
+
+## Self-check
+- [ ] Edge vs origin decision documented for each function.
+- [ ] Cold start measured and acceptable (<50ms target).
+- [ ] Bundle size within platform limits.
+- [ ] Fallback to origin implemented for edge failures.
+- [ ] Data locality compliant with regulatory requirements.
+- [ ] Cache headers set correctly at every layer.

package/.mindforge/skills/edtech-platform/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: edtech-platform
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: edtech platform, learning management system, adaptive learning algorithm, assessment engine, educational content delivery, student progress tracking, course management, LMS architecture, online learning platform, competency framework, learning path design, educational analytics
+---
+
+# Skill — EdTech Platform
+
+## When this skill activates
+This skill activates when building learning management systems (LMS), adaptive learning algorithms, assessment/quiz engines, course content delivery platforms, student progress tracking, competency frameworks, learning path recommendations, or educational analytics dashboards.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design learning object model: courses → modules → lessons → activities (video, reading, quiz, assignment), with prerequisite dependencies (DAG validation), completion criteria per activity type (watch 80% of video, pass quiz with 70%, submit assignment), and progress rollup to course level
+2. Model assessment engine: question bank with metadata (difficulty, topic tags, bloom's taxonomy level), quiz generation (random selection from pool, fixed seed for consistency), scoring rubrics (multiple choice auto-grade, short answer manual review, peer assessment), and partial credit support
+3. Map adaptive learning logic: knowledge graph (concepts and prerequisite relationships), learner profiling (mastery level per concept, learning velocity, preferred modalities), content recommendation (serve easier/harder content based on performance), and remediation paths (loop back to foundational concepts on failure)
+
+### During implementation
+- Implement content delivery with engagement tracking: video player with playback position persistence (resume from last position), event logging (play, pause, seek, speed change, completion), transcripts with search, captions in multiple languages, quality selection (adaptive bitrate for mobile), and download for offline access
+- Build assessment engine with anti-cheating measures: randomize question order, shuffle answer choices, time limits per question, lockdown browser detection (fullscreen enforcement, tab switch detection), plagiarism detection (Turnitin API, cosine similarity for text), and proctoring integration (webcam monitoring, eye tracking)
+- Design progress tracking with granular analytics: store activity completion events (user_id, activity_id, timestamp, score, time_spent), aggregate to module/course level, calculate metrics (completion rate, average score, time to completion), identify at-risk students (falling behind pace, multiple failed attempts), trigger interventions (reminder emails, instructor notifications)
+- Implement competency-based progression: define competencies with proficiency levels (novice, intermediate, advanced, expert), map learning activities to competencies, assess mastery through multiple evidence points (quiz scores, assignment grades, peer reviews), unlock next level only when threshold met (80% proficiency)
+- Build discussion forums with moderation: threaded conversations, upvote/downvote, instructor endorsements, tag filtering (question, announcement, discussion), spam detection (rate limiting, keyword filters, ML-based flagging), and content moderation queue
+
+### After implementation
+- Validate learning analytics accuracy: verify completion tracking (activity marked complete only when criteria met), score calculation (weighted averages for modules/courses), progress rollup (course progress reflects all module progress), and leaderboard consistency (rank students by total points, handle ties)
+- Test adaptive learning effectiveness: measure learning velocity (time to achieve 80% mastery per concept), retention rate (re-test after 1 week), engagement metrics (video watch time, quiz attempts, forum participation), compare adaptive vs linear paths (A/B test for cohort outcomes)
+- Execute accessibility compliance audit: WCAG 2.1 AA conformance (video captions, keyboard navigation, screen reader support), alternative formats (transcripts, audio descriptions), color contrast checks (4.5:1 for text), and assistive technology testing (NVDA, JAWS)
+
+## Self-check before task completion
+- [ ] Learning object hierarchy implemented: courses → modules → lessons → activities with prerequisite enforcement (DAG validation)
+- [ ] Content delivery tracks engagement: video playback position, event logs, transcript search, adaptive bitrate, offline download
+- [ ] Assessment engine supports multiple question types: multiple choice, short answer, essay, peer assessment, with auto-grading and manual review workflows
+- [ ] Anti-cheating measures active: randomized questions, time limits, lockdown browser, plagiarism detection, proctoring integration
+- [ ] Progress tracking granular: activity-level completion events, aggregate metrics at module/course level, at-risk student identification
+- [ ] Adaptive learning functional: knowledge graph, learner profiling, content recommendation based on mastery, remediation paths
+- [ ] Competency-based progression: proficiency levels, evidence-based mastery assessment, unlock gates for next level
+- [ ] Accessibility compliant: WCAG 2.1 AA (captions, keyboard nav, screen reader), alternative formats, color contrast