tractatus/NEXT_SESSION_OPENING_PROMPT.md

# Suggested Opening Prompt for Next Session

**Context**: First session with Anthropic API Memory system
**Project**: Tractatus multi-project AI governance platform
**Current Phase**: Testing & API Memory observation

---

## Recommended Opening Prompt

```
I'm continuing work on the Tractatus project. This is the FIRST SESSION using
Anthropic's new API Memory system.

Primary goals:
1. Run node scripts/session-init.js and observe framework initialization
2. Fix 3 MongoDB persistence test failures (1-2 hours estimated)
3. Investigate BoundaryEnforcer trigger logic (inst_016-018 compliance)
4. Document API Memory behavior vs. file-based system

Key context to observe:
- Do the 19 HIGH-persistence instructions load automatically?
- Does session-init.js detect previous session via API Memory?
- How does context pressure behave with new Memory system?
- What's the session length before compaction?

After initialization, start with: npm test -- --testPathPattern="tests/unit"
to diagnose framework test failures.

Read docs/SESSION_HANDOFF_2025-10-10.md for full context from previous session.
```

---

## Why This Prompt Works

### 1. **Establishes Context Immediately**
- "Continuing work on Tractatus" - Project continuity
- "FIRST SESSION with API Memory" - Critical context
- Links to handoff document - Full session history

### 2. **Clear Priorities**
- Primary goal: Observe API Memory behavior (new system testing)
- Secondary goal: Fix test failures (blocking work)
- Tertiary goal: Investigate framework issue (quality improvement)

### 3. **Explicit Observation Tasks**
- Questions about instruction loading
- Session detection behavior
- Context pressure patterns
- Session length metrics

### 4. **Actionable Next Steps**
- Run session-init.js (mandatory framework start)
- Run unit tests (diagnostic)
- Read handoff doc (full context)

### 5. **Leverages API Memory**
- Mentions "19 HIGH-persistence instructions" (test if Memory knows this)
- References previous session (test continuity)
- Links to specific files (test Memory's file awareness)

---

## Alternative: Shorter Version

If you prefer concise:

```
Tractatus project - FIRST session with API Memory. Run session-init.js,
observe framework behavior, fix test failures, then begin Phase 1.
See docs/SESSION_HANDOFF_2025-10-10.md for context.
```

**Pros**: Fast, direct
**Cons**: Less context for Memory system to latch onto

---

## Alternative: Explicit Testing Version

If you want to test Memory explicitly:

```
Tractatus project continuation. BEFORE running session-init.js:

Question 1: Do you remember the 19 active instructions from previous session?
Question 2: Can you summarize the current project status?
Question 3: What were we working on before this session started?

Then run session-init.js and compare file-based vs. Memory-based context.
```

**Pros**: Direct Memory system test
**Cons**: More manual, less workflow-oriented

---

## Recommended Approach

**Use the first prompt** (recommended version) because:
1. ✅ Natural workflow continuation
2. ✅ Tests Memory implicitly while working
3. ✅ Establishes priorities clearly
4. ✅ Maintains framework discipline (session-init first)
5. ✅ Balances observation with productivity

---

## What to Watch For in Response

### Indicators API Memory is Working

1. **Claude references previous session details** without reading files
   - Mentions "concurrent session architecture" work
   - Knows about inst_018 correction
   - Recalls BoundaryEnforcer investigation need

2. **Claude knows instruction count** before reading instruction-history.json
   - "I see we have 19 active instructions"
   - References specific instructions (inst_016, 017, 018, 019)

3. **Claude describes project status** without reading handoff
   - Knows we're at Phase 1 (after test fixes)
   - Mentions 50-64 hours remaining
   - References implementation plan

### Indicators API Memory is NOT Working (Yet)

1. **Claude asks basic questions** about project
   - "What is Tractatus?"
   - "What phase are we in?"
   - "What should I work on?"

2. **Claude needs to read files** for basic context
   - Immediately reads instruction-history.json
   - Reads handoff document for status
   - Asks for clarification on priorities

3. **Claude treats this as brand new session**
   - Doesn't reference previous work
   - Starts from scratch with framework
   - No continuity with past decisions

---

## Expected Outcomes

### Best Case (API Memory Excellent)
- Claude knows project status immediately
- Session lasts 100-150 messages before compaction
- Post-compaction continuation is seamless
- Framework state persists without file reads

### Realistic Case (API Memory Good)
- Claude has general context, needs some file reads
- Session lasts 50-80 messages before compaction
- Post-compaction is noticeably better than before
- Some framework state preserved

### Worst Case (API Memory Not Active Yet)
- Behavior identical to previous sessions
- 20-40 messages before compaction
- Full file reads needed for context
- session-init.js works exactly as before

**All cases are acceptable** - we're in observation mode, not optimization mode.

---

## Post-Session Data Collection

After next session, document:

1. **Session Length**: How many messages before compaction?
2. **File Operations**: Did session-init.js read all files?
3. **Instruction Persistence**: Were instructions auto-loaded?
4. **Context Continuity**: Did Claude remember previous session?
5. **Compaction Experience**: Was post-compaction handoff smoother?

This data informs:
- Phase 1 of session-init.js optimization (30 mins)
- Phase 4 implementation of inst_019 (4-6 hours)
- Phase 3.5 concurrent session architecture (4-6 hours)

---

**Prepared by**: Claude (claude-sonnet-4-5-20250929)
**Session**: 2025-10-10-api-memory-transition
**Date**: 2025-10-10