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