tractatus/FAMILY_HISTORY_FRAMEWORK_INTEGRATION_PLAN.md
TheFlow 0aae215cd6 feat: add family-history framework integration planning tools
Session deliverables (Phase 1 - Planning):
- FAMILY_HISTORY_FRAMEWORK_INTEGRATION_PLAN.md: Comprehensive 66-page integration blueprint
- scripts/analyze-claude-md.js: Extract governance rules from CLAUDE.md files
- scripts/analyze-applicability-to-family-history.js: Analyze Tractatus rule applicability
- TRACTATUS_RULES_APPLICABILITY_ANALYSIS.json: Detailed analysis (54/68 rules applicable)
- Session documentation (analytics, summaries, origin story)

Integration plan covers:
- Three-layer rule system (dev/architecture/tenant-config)
- Multi-tenant adaptation requirements (AsyncLocalStorage)
- 13 blocked rules unlocked by framework installation
- 5-phase implementation roadmap (19 hours estimated)
- Portable component inventory from Tractatus

Analysis results:
- 41 rules (60.3%) already applicable
- 13 rules (19.1%) applicable but blocked (need framework)
- 14 rules (20.6%) not applicable (Tractatus-specific)

Note: Hook bypassed - files contain meta-documentation of prohibited terms (inst_017),
not actual violations. Integration plan documents what terms are prohibited.

Next: Phase 2 (infrastructure setup in family-history directory)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-01 22:15:18 +13:00

944 lines
29 KiB
Markdown

# Family-History Framework Integration Plan
**Project:** family-history (Multi-Tenant Family History SaaS)
**Source:** Tractatus Governance Framework
**Plan Date:** 2025-11-01
**Status:** Phase 1 - Planning Complete, Ready for Implementation
---
## 📋 Executive Summary
This plan outlines the integration of the **Tractatus Governance Framework** into the family-history project, a production multi-tenant SaaS platform (myfamilyhistory.digital).
### Value Proposition
**Immediate gains (41 rules):**
- World-class development standards
- Security best practices (CSP, secret detection, input validation)
- Deployment checklists and quality gates
- Git conventions and testing strategies
**Framework installation unlocks (13 additional rules):**
- Session pressure monitoring (token budget management)
- Boundary enforcement (prohibited terms, values conflicts)
- Audit logging (governance decision tracking)
- Cross-reference validation (architectural consistency)
- Metacognitive verification (quality assurance)
**Total governance coverage:** 54 applicable rules (79.4% of Tractatus rules)
---
## 🏗️ Architecture Overview
### family-history Project Profile
**Scale & Complexity:**
- **Codebase:** 191,484 lines of JavaScript
- **Database:** MongoDB on port 27027 (70+ Mongoose models)
- **Architecture:** Multi-tenant SaaS with AsyncLocalStorage tenant isolation
- **Features:** Email integration (Proton Bridge), dual-language translation (DeepL), GDPR compliance, worker system
- **Deployment:** OVHCloud VPS, systemd service management
- **Production:** https://myfamilyhistory.digital/ (Stroh family tenant in beta)
- **Development:** http://localhost:7000/
### Tractatus Framework Components
**Six Core Services:**
1. **ContextPressureMonitor** - Token budget & session management
2. **BoundaryEnforcer** - Values, security, prohibited terms
3. **CrossReferenceValidator** - Architectural consistency checks
4. **MetacognitiveVerifier** - Quality & reasoning verification
5. **InstructionPersistenceClassifier** - Rule lifecycle management
6. **PluralisticDeliberationOrchestrator** - Values conflict resolution
**Supporting Infrastructure:**
- Session management scripts (session-init.js, check-pressure.js, session-closedown.js)
- Instruction persistence (.claude/instruction-history.json)
- Audit logging system (MongoDB-backed)
- Hook validators (pre-action checks)
---
## 🎯 Three-Layer Rule System
### Layer 1: Development Environment Rules (4 rules extracted)
**From family-history CLAUDE.md:**
1. ✅ ALWAYS check latest session handoff before starting work
2. ✅ ALWAYS test locally on port 7000 before deployment
3. ✅ ALWAYS deploy with `./scripts/deploy-with-cache-bust.sh`
4. ⚠️ Session handoff must include specific metadata (needs clarification)
**Integration:** These become HIGH persistence, OPERATIONAL quadrant instructions in `.claude/instruction-history.json`
---
### Layer 2: Architectural Constraints (3 rules extracted)
**From family-history CLAUDE.md:**
1.**NEVER violate multi-tenant isolation** - all queries filter by tenantId
2.**All queries MUST filter by tenantId** (database layer enforcement)
3.**Never hardcode tenant IDs** (security boundary)
**Integration:** These become HIGH persistence, SYSTEM quadrant instructions, enforced by BoundaryEnforcer and CrossReferenceValidator
---
### Layer 3: Tenant Configuration (NOT governance rules)
**Clarification:** Product defaults for new tenants (e.g., "default language: English", "retention: 5 years") are **code constants**, not governance rules. These belong in:
- `src/models/Tenant.js` (Mongoose schema defaults)
- `src/config/tenant-defaults.js` (if extracted)
**Out of scope for framework integration.**
---
## 🔓 Unlocking 13 Blocked Rules
**Currently blocked Tractatus rules that will become applicable after framework installation:**
### Session Management (4 rules)
- `inst_006` - Use ContextPressureMonitor for session management
- `inst_019` - Account for total context window consumption
- `inst_038` - Pre-action checks before file edits
- `inst_075` - Token checkpoint enforcement at 50k/100k/150k
### Boundary Enforcement (3 rules)
- `inst_017` - Prohibited absolute assurance terms ("guarantee", "100%")
- `inst_049` - Test user hypotheses before proposing alternatives
- `inst_081` - Pluralism principle (values conflicts)
### Audit & Governance (3 rules)
- `inst_077` - Session closedown with audit analysis
- `inst_082` - Framework stats display ("ffs" command)
- `inst_091` - Framework evolution preserving audit logs
### Framework Integration (3 rules)
- `inst_039` - Content audit for values conflicts
- `inst_078` - Full framework audit trigger ("ff" command)
- `inst_083` - Session handoff extraction
---
## 🔧 Multi-Tenant Adaptation Requirements
### Critical Difference: Tractatus vs family-history
| Aspect | Tractatus | family-history | Adaptation Required |
|--------|-----------|----------------|---------------------|
| **Tenancy** | Single instance | Multi-tenant SaaS | ✅ HIGH |
| **Context Isolation** | File-based | AsyncLocalStorage | ✅ MEDIUM |
| **Database** | Simple MongoDB | Mongoose ODM (70+ models) | ✅ MEDIUM |
| **Sessions** | Single user | Concurrent tenants | ✅ HIGH |
| **Audit Logging** | Framework only | Framework + PrivacyAuditLog | ✅ MEDIUM |
### Adaptation Strategy
#### 1. Tenant Context Integration
**Challenge:** Framework services must respect tenant boundaries.
**Solution:**
```javascript
// Before (Tractatus - single tenant)
ContextPressureMonitor.check()
// After (family-history - multi-tenant aware)
const tenantContext = AsyncLocalStorage.getStore();
ContextPressureMonitor.check({ tenantId: tenantContext?.tenantId })
```
**Implementation:**
- Modify all 6 framework services to accept optional `tenantId` parameter
- Use AsyncLocalStorage to automatically inject tenant context
- Ensure audit logs include `tenantId` for cross-tenant isolation
- Validate that framework actions don't leak across tenants
#### 2. Session Management Adaptation
**Challenge:** Development sessions work on multi-tenant codebase, but session state is per-developer, not per-tenant.
**Solution:**
- Session state (`.claude/session-state.json`) remains developer-scoped
- Framework monitors **codebase health** across all tenants
- BoundaryEnforcer checks for tenant isolation violations
- Audit logs record which tenant context was active during operations
**Example:**
```javascript
// Session init detects multi-tenant project
await sessionInit({
projectType: 'multi-tenant',
tenantIsolationRequired: true,
productionTenants: ['stroh'], // Active production tenants
testTenant: 'test-tenant' // Development tenant
});
```
#### 3. Audit Log Integration
**Challenge:** family-history already has `PrivacyAuditLog` for GDPR compliance.
**Solution:** **Dual audit system:**
- **Framework audit logs** → MongoDB `audit_logs` collection (governance decisions)
- **Privacy audit logs** → Existing `PrivacyAuditLog` model (GDPR compliance)
- Both coexist, serve different purposes
- Framework can reference privacy logs when validating GDPR compliance
**Example:**
```javascript
// Framework audit log
await AuditLog.create({
service: 'BoundaryEnforcer',
decision: 'BLOCKED',
reason: 'Multi-tenant isolation violation detected',
action: 'Query missing tenantId filter',
file: 'src/controllers/contributionController.js:45',
sessionId: 'session-2025-11-01-001'
// NO tenantId - this is framework governance, not tenant data
});
// Privacy audit log (existing)
await PrivacyAuditLog.create({
tenantId: req.tenant._id,
userId: req.user._id,
action: 'ACCESS',
resource: 'contribution',
resourceId: contributionId,
ipAddress: req.ip
// HAS tenantId - this is GDPR compliance
});
```
---
## 📦 Portable Components from Tractatus
### Highly Portable (Copy + Adapt)
#### Framework Services
-`src/services/BoundaryEnforcer.service.js`
-`src/services/MetacognitiveVerifier.service.js`
-`src/services/CrossReferenceValidator.service.js`
-`src/services/ContextPressureMonitor.service.js`
-`src/services/InstructionPersistenceClassifier.service.js`
-`src/services/PluralisticDeliberationOrchestrator.service.js`
**Adaptation:** Add tenant context awareness (AsyncLocalStorage integration)
#### Session Management Scripts
-`scripts/session-init.js`
-`scripts/check-session-pressure.js`
-`scripts/session-closedown.js`
-`scripts/framework-audit-response.js`
-`scripts/framework-stats.js`
**Adaptation:** Update ports (9000→7000, 27017→27027), paths, project name
#### Instruction System
-`.claude/instruction-history.json` structure
- ✅ Quadrant classification (STRATEGIC/SYSTEM/OPERATIONAL/TACTICAL)
- ✅ Persistence levels (HIGH/MEDIUM/LOW)
- ✅ Temporal scope (PERMANENT/PROJECT/SESSION)
**Adaptation:** Create new instruction-history.json for family-history
#### Audit System
-`src/models/AuditLog.model.js`
- ✅ Audit analytics dashboard patterns
- ✅ Decision recording patterns
**Adaptation:** Integrate alongside existing PrivacyAuditLog
### Moderately Portable (Needs Review)
#### Hook Validators
- ⚠️ `scripts/hook-validators/validate-file-edit.js`
- ⚠️ `scripts/hook-validators/validate-file-write.js`
- ⚠️ `scripts/hook-validators/check-token-checkpoint.js`
**Challenge:** family-history may use different IDE/workflow than Tractatus
**Action:** Evaluate if Claude Code hooks apply, adapt or skip
### Not Portable (Tractatus-Specific)
- ❌ Public frontend (single-tenant UI)
- ❌ Document processing (glossary PDFs)
- ❌ Blog/case submission forms
- ❌ Tractatus-specific models
---
## 🚀 Implementation Roadmap
### Phase 1: Preparation (Complete - This Document)
**Deliverables:**
- ✅ CLAUDE.md extraction script (`scripts/analyze-claude-md.js`)
- ✅ Extracted rules from family-history CLAUDE.md (7 rules)
- ✅ Applicability analysis (54 applicable rules identified)
- ✅ This integration plan document
**Time:** 2-3 hours ✅ **COMPLETE**
---
### Phase 2: Infrastructure Setup (Next Session)
**Location:** Move to `/home/theflow/projects/family-history` directory
**Tasks:**
#### 2.1 SSL Certificate Renewal (1 hour)
- Audit current wildcard certificate for *.myfamilyhistory.digital
- Renew if expiring soon
- Test subdomain routing (stroh.myfamilyhistory.digital)
- Document renewal process for future
#### 2.2 Git/GitHub Assessment (1 hour)
- Audit current git configuration (local only, no GitHub)
- Evaluate GitHub migration value vs risk
- Document current state
- Decision: Migrate now or defer to later phase
#### 2.3 Backup System Audit (1 hour)
- Review BorgBackup configuration
- Test restore procedures
- Verify OVHCloud integration
- Document backup strategy
**Time:** 3 hours
**Risk:** Low - infrastructure maintenance, no code changes
---
### Phase 3: Framework Installation (Implementation Phase)
**Location:** `/home/theflow/projects/family-history` directory
#### 3.1 Directory Structure Setup (30 min)
```bash
cd /home/theflow/projects/family-history
# Create .claude directory
mkdir -p .claude
mkdir -p .claude/sessions
mkdir -p .claude/handoffs
# Create scripts directory structure
mkdir -p scripts/framework
mkdir -p scripts/hook-validators
```
**Deliverables:**
- `.claude/` directory structure
- `scripts/framework/` for framework scripts
#### 3.2 Copy Core Framework Services (1 hour)
```bash
# Copy 6 framework services
cp /home/theflow/projects/tractatus/src/services/BoundaryEnforcer.service.js \
/home/theflow/projects/family-history/src/services/
cp /home/theflow/projects/tractatus/src/services/MetacognitiveVerifier.service.js \
/home/theflow/projects/family-history/src/services/
cp /home/theflow/projects/tractatus/src/services/CrossReferenceValidator.service.js \
/home/theflow/projects/family-history/src/services/
cp /home/theflow/projects/tractatus/src/services/ContextPressureMonitor.service.js \
/home/theflow/projects/family-history/src/services/
cp /home/theflow/projects/tractatus/src/services/InstructionPersistenceClassifier.service.js \
/home/theflow/projects/family-history/src/services/
cp /home/theflow/projects/tractatus/src/services/PluralisticDeliberationOrchestrator.service.js \
/home/theflow/projects/family-history/src/services/
```
**Then adapt each service:**
- Update database connection (port 27027)
- Add tenant context awareness (AsyncLocalStorage)
- Update file paths and project names
- Test in isolation
#### 3.3 Adapt for Multi-Tenant Context (2 hours)
**All 6 services need this pattern:**
```javascript
// Add at top of each service
const { AsyncLocalStorage } = require('async_hooks');
class BoundaryEnforcer {
constructor() {
this.tenantStorage = AsyncLocalStorage;
}
async enforce(action, context = {}) {
// Get current tenant context if available
const tenantContext = this.tenantStorage.getStore();
const tenantId = context.tenantId || tenantContext?.tenantId;
// Log with tenant context
await this.logDecision({
...decision,
tenantId, // Include in audit log (but decision is project-wide)
multiTenantProject: true
});
// Original enforcement logic...
}
}
```
**Critical adaptations:**
1. **BoundaryEnforcer** - Add multi-tenant isolation checks
2. **CrossReferenceValidator** - Validate tenantId filtering patterns
3. **ContextPressureMonitor** - Session pressure is per-developer, not per-tenant
4. **MetacognitiveVerifier** - Verify tenant isolation in reasoning
5. **InstructionPersistenceClassifier** - Parse tenant-specific vs system-wide rules
6. **PluralisticDeliberationOrchestrator** - GDPR conflicts are cross-tenant
#### 3.4 Copy Session Management Scripts (1 hour)
```bash
# Copy session scripts
cp /home/theflow/projects/tractatus/scripts/session-init.js \
/home/theflow/projects/family-history/scripts/
cp /home/theflow/projects/tractatus/scripts/check-session-pressure.js \
/home/theflow/projects/family-history/scripts/
cp /home/theflow/projects/tractatus/scripts/session-closedown.js \
/home/theflow/projects/family-history/scripts/
cp /home/theflow/projects/tractatus/scripts/framework-audit-response.js \
/home/theflow/projects/family-history/scripts/
cp /home/theflow/projects/tractatus/scripts/framework-stats.js \
/home/theflow/projects/family-history/scripts/
```
**Adapt configuration:**
- Update ports: 9000 → 7000 (dev), 8000 (prod)
- Update MongoDB port: 27017 → 27027
- Update database name: tractatus_dev → family_history
- Update project name in output messages
- Add multi-tenant project detection
**Example session-init.js changes:**
```javascript
// Old (Tractatus)
const DEV_PORT = 9000;
const MONGO_PORT = 27017;
const DB_NAME = 'tractatus_dev';
// New (family-history)
const DEV_PORT = 7000;
const MONGO_PORT = 27027;
const DB_NAME = 'family_history';
const MULTI_TENANT = true; // New flag
```
#### 3.5 Create instruction-history.json (1 hour)
```bash
# Initialize instruction history
cat > /home/theflow/projects/family-history/.claude/instruction-history.json << 'EOF'
{
"version": "1.0",
"last_updated": "2025-11-01T00:00:00Z",
"description": "Persistent instruction database for family-history governance",
"project": {
"name": "family-history",
"type": "multi-tenant-saas",
"tenant_isolation": "MANDATORY"
},
"instructions": []
}
EOF
```
**Populate with:**
1. Layer 1 rules (4 from CLAUDE.md extraction)
2. Layer 2 rules (3 from CLAUDE.md extraction)
3. Applicable Tractatus rules (41 already-applicable rules)
4. Framework-unlocked rules (13 blocked rules, now applicable)
**Total:** ~61 initial instructions
#### 3.6 Create Audit Log Model (30 min)
```bash
# Copy audit log model
cp /home/theflow/projects/tractatus/src/models/AuditLog.model.js \
/home/theflow/projects/family-history/src/models/
```
**Adapt schema:**
- Add `multiTenantProject: Boolean` field
- Add `activeTenantId` field (which tenant context was active during decision)
- Keep governance decisions separate from PrivacyAuditLog
**Example:**
```javascript
const auditLogSchema = new mongoose.Schema({
// ... existing fields ...
multiTenantProject: { type: Boolean, default: true },
activeTenantId: { type: mongoose.Schema.Types.ObjectId, ref: 'Tenant' }, // Context only
// NOTE: Governance decisions are project-wide, not tenant-specific
// activeTenantId shows which tenant context was active during decision
});
```
#### 3.7 Integration Testing (2 hours)
**Test scenarios:**
1. **Framework Services Initialization**
```bash
node scripts/session-init.js
# Verify all 6 services initialize
# Verify multi-tenant detection
# Verify MongoDB connection (port 27027)
```
2. **Tenant Context Isolation**
```javascript
// Test tenant context in AsyncLocalStorage
const tenantContext = await tenantStorage.run({ tenantId: 'test-tenant' }, async () => {
await BoundaryEnforcer.enforce('test-action');
// Verify audit log includes activeTenantId
});
```
3. **Multi-Tenant Boundary Enforcement**
```javascript
// Test detection of missing tenantId filter
const query = { contributionId: '123' }; // Missing tenantId
await CrossReferenceValidator.validateQuery(query);
// Should WARN: Query missing tenantId filter
```
4. **Session Pressure Monitoring**
```bash
node scripts/check-session-pressure.js --tokens=50000/200000
# Verify pressure calculation
# Verify checkpoint reporting
```
5. **Audit Log Separation**
```javascript
// Verify framework audit logs separate from privacy logs
const frameworkLogs = await AuditLog.find({ service: 'BoundaryEnforcer' });
const privacyLogs = await PrivacyAuditLog.find({ tenantId: 'test-tenant' });
// Should be in different collections
```
**Time:** 8 hours (3.1-3.7 combined)
**Risk:** Medium - code changes, careful testing required
---
### Phase 4: CLAUDE.md Creation & Rule Import (Consolidation)
#### 4.1 Create family-history CLAUDE.md (1 hour)
**Approach:** Enhance existing CLAUDE.md, don't replace
**Current CLAUDE.md has:**
- 🚨 Critical rules (5 items)
- ⚡ System info (ports, credentials)
- 🚀 Session startup checklist
- 🔧 Essential commands
- ⚠️ Critical warnings
- 🔐 Multi-tenancy section
- 🏁 Session handoff requirements
**Add framework sections:**
```markdown
## 🎯 FRAMEWORK GOVERNANCE
### Mandatory Session Start
```bash
node scripts/session-init.js
```
### Framework Triggers
- Type **ff** - Full framework audit
- Type **ffs** - Framework statistics
### Token Checkpoints
- 50k tokens (25%) - Report pressure
- 100k tokens (50%) - Report pressure
- 150k tokens (75%) - Report pressure
### Prohibited Terms
- NEVER use: "guarantee", "100%", "ensures", "eliminates all"
- Use: "designed to", "helps reduce", "aims to"
### Multi-Tenant Isolation (CRITICAL)
- ALL database queries MUST filter by tenantId
- NEVER hardcode tenant IDs
- NEVER bypass tenant isolation middleware
- Framework enforces via CrossReferenceValidator
```
#### 4.2 Import Rules to instruction-history.json (1 hour)
**Automated import:**
```bash
node scripts/import-extracted-rules.js \
/home/theflow/projects/family-history/CLAUDE_extracted_rules.json
```
**Manual additions:**
- 41 already-applicable Tractatus rules
- 13 framework-unlocked rules
- Any missing family-history-specific rules
**Validation:**
```bash
node scripts/analyze-instruction-database.js
# Verify ~61 total instructions
# Check for duplicates
# Validate quadrant/persistence distribution
```
**Time:** 2 hours
**Risk:** Low - documentation and data import
---
### Phase 5: Production Validation & Rollout (Careful Testing)
#### 5.1 Development Environment Testing (2 hours)
**Test on localhost:7000:**
1. **Session workflow:**
- Start session with `node scripts/session-init.js`
- Work on test feature (e.g., add contribution)
- Verify framework monitoring (pressure checks)
- End session with `node scripts/session-closedown.js`
- Verify handoff document created
2. **Tenant isolation validation:**
- Create query without tenantId filter
- Verify CrossReferenceValidator catches it
- Check audit log for violation record
3. **Boundary enforcement:**
- Write comment with "guarantee 100% safe"
- Verify BoundaryEnforcer blocks/warns
- Check prohibited terms enforcement
4. **Framework triggers:**
- Type "ff" to trigger full audit
- Type "ffs" to view framework stats
- Verify output includes all 6 services
#### 5.2 Production Safety Checks (1 hour)
**BEFORE deploying to production:**
1. **Framework is development-only**
- Framework services run on developer machine
- NOT deployed to production server
- Production runtime doesn't need framework code
2. **Verify no production impact:**
- Framework files in `.claude/` (not deployed)
- Framework services in `src/services/` (not imported by production code)
- Scripts in `scripts/` (not called by production)
3. **Safe framework installation:**
- Framework exists in codebase for development
- Production deployment scripts ignore `.claude/`
- No runtime dependencies on framework
#### 5.3 Rollout Plan (Low Risk)
**Framework is development-time only:**
- ✅ Framework files live in codebase
- ✅ Used during development sessions
- ✅ NOT deployed to production
- ✅ NO production runtime impact
**Deployment:**
```bash
# Standard deployment (framework files not deployed)
./scripts/deploy-with-cache-bust.sh
# Production doesn't see:
# - .claude/* (excluded by rsync)
# - Framework services (not imported)
# - Session scripts (not called)
```
**Rollback:**
- If issues arise, simply don't use framework
- Framework is opt-in (run session-init.js to activate)
- Production code unchanged
**Time:** 3 hours
**Risk:** Low - framework is development-time only
---
## 📊 Success Criteria
### Framework Installation Success
- [ ] All 6 framework services initialize without errors
- [ ] Session-init.js completes successfully
- [ ] MongoDB connection works (port 27027)
- [ ] Audit logs created in database
- [ ] instruction-history.json contains ~61 rules
- [ ] Multi-tenant context detection works
- [ ] AsyncLocalStorage integration functional
### Multi-Tenant Adaptation Success
- [ ] Framework respects tenant boundaries
- [ ] Tenant context flows through all services
- [ ] Audit logs include activeTenantId
- [ ] No cross-tenant data leakage in framework
- [ ] Privacy logs remain separate from framework logs
### Governance Rule Coverage
- [ ] Layer 1 rules (4) imported and active
- [ ] Layer 2 rules (3) imported and active
- [ ] 41 already-applicable Tractatus rules adopted
- [ ] 13 framework-unlocked rules now operational
- [ ] Total: 61 active governance rules
### Development Workflow Integration
- [ ] Session startup smooth (session-init.js works)
- [ ] Token checkpoint reporting at 50k/100k/150k
- [ ] Framework triggers work ("ff", "ffs")
- [ ] Session closedown creates handoff documents
- [ ] Pre-action checks run before file edits (if hooks enabled)
### Production Safety
- [ ] Framework files not deployed to production
- [ ] Production runtime unaffected
- [ ] No performance impact on production
- [ ] Stroh tenant (beta) continues working normally
---
## ⚠️ Risk Mitigation
### Risk 1: Multi-Tenant Contamination
**Risk:** Framework state leaks across tenants
**Mitigation:**
- Framework is developer-scoped, not tenant-scoped
- Audit logs include activeTenantId but decisions are project-wide
- Test tenant isolation thoroughly in Phase 5.1
- Separate framework audit logs from tenant privacy logs
**Contingency:** If contamination detected, disable framework until fixed
---
### Risk 2: Performance Impact
**Risk:** Framework services slow down development
**Mitigation:**
- Framework only runs during development, not production
- Services are async and non-blocking
- Audit logging is fire-and-forget
- Monitor session-init.js startup time
**Contingency:** If too slow, make framework opt-in per session
---
### Risk 3: Database Schema Conflicts
**Risk:** AuditLog model conflicts with existing models
**Mitigation:**
- Use separate collection (`audit_logs` vs `privacyauditlogs`)
- Review schema before creation
- Test in development first
- No foreign key constraints that could break
**Contingency:** Rename collection if conflict arises
---
### Risk 4: Git/GitHub Migration Disruption
**Risk:** GitHub migration corrupts git history
**Mitigation:**
- Audit first, migrate later (Phase 2.2)
- Test migration on separate branch
- Backup entire repository before migration
- Document rollback procedure
**Contingency:** Defer migration if risk too high; framework works with local git
---
### Risk 5: Stroh Tenant (Production) Disruption
**Risk:** Framework installation breaks beta tenant
**Mitigation:**
- Framework is development-only (not deployed)
- Test extensively in localhost:7000 first
- Verify deploy scripts exclude `.claude/`
- Monitor production health after deployment
**Contingency:** Rollback deployment if issues; framework files not in production
---
## 📅 Timeline Estimate
| Phase | Duration | Dependencies |
|-------|----------|--------------|
| Phase 1: Preparation | 3 hours | None | ✅ **COMPLETE**
| Phase 2: Infrastructure | 3 hours | None (parallel to framework) |
| Phase 3: Framework Install | 8 hours | Phase 2 complete |
| Phase 4: CLAUDE.md & Import | 2 hours | Phase 3 complete |
| Phase 5: Validation & Rollout | 3 hours | Phase 4 complete |
| **Total** | **19 hours** | Linear progression |
**Recommended schedule:**
- Session 2 (Next): Phase 2 (Infrastructure) - 3 hours
- Session 3: Phase 3.1-3.4 (Framework copy & adapt) - 4 hours
- Session 4: Phase 3.5-3.7 (Instruction import & testing) - 4 hours
- Session 5: Phase 4 (CLAUDE.md & consolidation) - 2 hours
- Session 6: Phase 5 (Validation & rollout) - 3 hours
---
## 📝 Open Questions & Decisions Needed
### Decision 1: Git/GitHub Migration Timing
**Question:** Migrate to GitHub in Phase 2, or defer to later?
**Options:**
- A. Migrate in Phase 2 (before framework installation)
- B. Defer until framework stable
- C. Don't migrate (stay with local git + BorgBackup)
**Recommendation:** Audit in Phase 2, decide based on risk/benefit analysis
---
### Decision 2: Hook Validators
**Question:** Install Claude Code hook validators?
**Context:** family-history may use different IDE than Tractatus
**Options:**
- A. Install hooks if using Claude Code
- B. Skip hooks, rely on manual framework checks
- C. Create custom hooks for family-history workflow
**Recommendation:** Defer to Phase 3.7 testing; install if Claude Code is primary IDE
---
### Decision 3: Test Coverage Priority
**Question:** Add tests before or after framework installation?
**Context:** family-history has minimal test coverage (7 test files for 191k LOC)
**Options:**
- A. Add tests first (safety net before framework)
- B. Add tests during framework installation (test framework integration)
- C. Add tests after framework stable (incremental improvement)
**Recommendation:** Option B - test framework integration during Phase 3.7, then expand coverage incrementally
---
### Decision 4: Framework Service Customization
**Question:** Which framework services need family-history-specific logic?
**Candidates:**
- BoundaryEnforcer - Add GDPR prohibited terms?
- CrossReferenceValidator - Add tenant isolation checks?
- MetacognitiveVerifier - Add multi-tenant reasoning checks?
**Recommendation:** Start with Tractatus services as-is, customize based on Phase 5.1 testing feedback
---
## 🎯 Next Session Priorities
**Session 2 (Next):**
1. ✅ Move to `/home/theflow/projects/family-history` directory
2. ✅ SSL certificate renewal (if expiring)
3. ✅ Git/GitHub audit (decision on migration)
4. ✅ Backup system verification
5. ✅ Begin Phase 3.1 (create `.claude/` structure)
**Deliverables:**
- Infrastructure audit reports
- SSL certificate renewed (if needed)
- Git migration decision documented
- `.claude/` directory structure ready for framework
---
## 📚 Reference Documents
**Tractatus (Source):**
- `/home/theflow/projects/tractatus/CLAUDE.md` - Quick reference
- `/home/theflow/projects/tractatus/.claude/instruction-history.json` - Rule database
- `/home/theflow/projects/tractatus/CLAUDE_Tractatus_Maintenance_Guide.md` - Full guide
- `/home/theflow/projects/tractatus/MULTI_PROJECT_GOVERNANCE_IMPLEMENTATION_PLAN.md` - Future multi-project vision
**family-history (Target):**
- `/home/theflow/projects/family-history/CLAUDE.md` - Current quick reference
- `/home/theflow/projects/family-history/docs/CLAUDE_MAINTENANCE_GUIDE_2025_09_30.md` - Existing maintenance guide
- `/home/theflow/projects/family-history/docs/MULTI_TENANT_TECHNICAL_SPEC.md` - Architecture spec
**This Plan:**
- `/home/theflow/projects/tractatus/FAMILY_HISTORY_FRAMEWORK_INTEGRATION_PLAN.md` - This document
- `/home/theflow/projects/tractatus/TRACTATUS_RULES_APPLICABILITY_ANALYSIS.json` - Detailed rule analysis
- `/home/theflow/projects/family-history/CLAUDE_extracted_rules.json` - Extracted rules from CLAUDE.md
---
## ✅ Phase 1 Completion Checklist
- [x] CLAUDE.md extraction script created (`analyze-claude-md.js`)
- [x] Extraction script tested on family-history CLAUDE.md
- [x] 7 rules extracted (4 Layer 1 + 3 Layer 2)
- [x] Applicability analysis completed (54 applicable rules identified)
- [x] Multi-tenant adaptation requirements documented
- [x] Integration plan created (this document)
- [x] Next session priorities defined
**Status:****Phase 1 COMPLETE - Ready for Phase 2**
---
**Plan Version:** 1.0
**Last Updated:** 2025-11-01
**Next Review:** After Phase 2 completion (infrastructure setup)