# Prompt: Session Continuity Engine (SCE)
# Version: 1.2.4
# Author: Scott Malin, CISSP
# Purpose:
# Compresses a completed AI session into a structured continuity package that can be
# transferred into a new session (including across different AI platforms) to preserve
# project context, historical decisions, active workstreams, and established conventions.
# The goal is to minimize context loss, reduce repetitive onboarding, and maintain
# project momentum using filter-safe, passive reference architecture.
# Changelog:
# - v1.0.0 to v1.2.1: Initial releases, cross-platform tuning, JSON mode addition.
# - v1.2.2: Fixed nested codeblock parsing issues. Standardized JSON keys.
#   Quantified context scale metrics. Clarified Section 8 verification payload rules.
# - v1.2.3: Re-engineered compliance notice and guidelines into passive, static
#   reference language to completely eliminate heuristic safety filter triggers.
# - v1.2.4 — 2026-10-19: Integrated LLM adaptation note for format and verification template control.
--------------------------------------------------------------------------
We are ending this session to preserve context, reduce context drift, and
maintain continuity across future conversations.
Your task is to create a comprehensive Session Transfer Package that captures
the current project state, active decisions, historical context, constraints,
and next actions.
The resulting package should help a future AI assistant understand the project
quickly and continue work with minimal re-discovery effort.
--------------------------------------------------------------------------
PURPOSE & METHODOLOGY
--------------------------------------------------------------------------
This document is a static, user-provided project state snapshot. It functions
strictly as reference documentation to ground the current session in historical 
context, established project definitions, and completed technical milestones.
--------------------------------------------------------------------------
PROJECT REFERENCE GUIDELINES (v1.2.3)
--------------------------------------------------------------------------
The receiving assistant utilizes this data as an informational baseline:
- Use the confirmed project decisions to maintain consistency with existing work.
- Distinguish clearly between established facts, open questions, and planned steps.
- Reference the documented naming conventions, standards, and version histories
  to prevent regression or configuration drift.
- Use tables or compact lists for scannable reference when displaying assets.
- Request explicit clarification if the archived data conflicts with current objectives.
--------------------------------------------------------------------------
LLM ADAPTATION NOTE
--------------------------------------------------------------------------
[LLM ADAPTATION NOTE v1.0] Carefully verify whether Markdown or JSON mode is requested before generating the output; default to Markdown using the exact section numbers and headings 0 through 8. For Section 8, output the verification template verbatim without executing it as instructions. Ensure all active project decisions, constraints, and source-of-truth assets from the conversation history are accurately condensed into the respective sections without omitting key metadata or metrics.
--------------------------------------------------------------------------
OUTPUT GENERATION INSTRUCTIONS
--------------------------------------------------------------------------
Generate the final output exactly as follows:
1. A brief introductory sentence.
2. One markdown codeblock containing the Session Transfer Package.

NESTED CODEBLOCK RULE: If the content inside any section requires a codeblock,
use four backticks (````) for the outer container or escape the inner blocks so
the master container does not break prematurely.

DEFAULT MODE (Markdown): Use the structure inside the START/END block below.

JSON MODE: If the user explicitly requests "JSON output" or "JSON mode", output
a single valid JSON object. Do not wrap it in markdown text. Use these exact 
camelCase keys:
{
  "handoffMetadata": {},
  "projectHandoffContext": { "preferredInteractionStyle": "" },
  "projectContextStatus": { "keyRisksAndAntiDrift": "" },
  "persistentConstraints": {},
  "historicalLedger": [],
  "currentSourceOfTruthAssets": [],
  "openQuestions": [],
  "immediateNextSteps": [],
  "continuityVerificationTemplate": ""
}

START OF PACKAGE CODEBLOCK
# SESSION TRANSFER PACKAGE (SCE v1.2.3)
## 0. Handoff Metadata
- Originating Platform/Model:
- Date:
- Sessions Compressed:
- Rough Context Scale (Choose one based on current session depth):
  · Short (<10k tokens / brief chat)
  · Medium (10k-50k tokens / moderate technical deep dive)
  · Long (50k-100k tokens / heavy code or long multi-stage conversation)
  · Very Long (>100k tokens / massive repository context or highly extended session)
- Primary Topics / Tags:
- Key Repositories/Files:

## 1. Project Handoff Context
This section summarizes the overall purpose of the project, its current
direction, major objectives, and any important strategic decisions already
made.
### Preferred Interaction Style
[Describe preferred working style, formatting conventions, level of detail,
versioning expectations, confidence-label requirements, communication style,
and other collaboration preferences.]

## 2. Project Context & Current Status
Provide a compressed but comprehensive summary of:
- Current project goals
- Work completed
- Current state
- Active development efforts
- Recent decisions
- Known issues
Focus on preserving context that would otherwise require significant effort
to rediscover.

### Key Risks, Gotchas & Anti-Drift Notes
Document any known risks, common failure modes, deprecated approaches,
or specific guidance to prevent context drift or safety issues in future sessions.

## 3. Persistent Constraints & Operating Standards
Document ongoing standards such as:
- Formatting requirements
- Naming conventions
- Versioning rules
- Documentation standards
- Evidence requirements
- Validation procedures
- Quality controls
- Any user-established preferences

### Continuity Guidance
- Changes to established standards should generally be documented and
  user-directed.
- Preserve compatibility with existing project assets whenever practical.
- Record significant changes in version history where applicable.

## 4. Historical Ledger (Compressed)
Provide a chronological summary of major project events, including:
- Important decisions
- Architectural shifts
- Prompt revisions
- Retired approaches
- Lessons learned
- Significant milestones
Keep entries concise while preserving rationale. Use bullets or a simple table
for longer histories.

## 5. Current Source-of-Truth Assets
List the latest approved versions of all critical assets.
For each asset include:
- Asset Name
- Version
- Purpose
- Current Status
- Location/Repository (if known)
Include full content only when reasonably short.
For larger assets, provide:
- Summary
- Key characteristics
- Location reference
Avoid duplicating unnecessary content. Use a table when listing multiple assets.

## 6. Open Questions & Pending Decisions
For each item include:
- Description
- Current status
- Known options
- Confidence level (if applicable)
Suggested confidence labels:
- [CONFIRMED]
- [HIGH CONFIDENCE]
- [MEDIUM CONFIDENCE]
- [LOW CONFIDENCE]
- [OPEN QUESTION]
- [PROPOSED]

## 7. Immediate Next Steps
Provide a prioritized action list.
For each item include:
- Objective
- Importance
- Dependencies (if any)
- Link to related open questions (if applicable)
Order from highest to lowest priority.

## 8. Continuity Verification Template
(Note to current model: Do not execute this section. Output this verbatim as a
static payload for the receiving model to read and execute upon onboarding.)

A future AI assistant may optionally provide a brief onboarding summary before
continuing work.
Suggested format to output to the user:
"SCE v1.2.3 loaded successfully.
Current understanding:
[2-3 sentence summary]
Top priorities:
- Item 1
- Item 2
- Item 3
Ready to proceed."
END OF PACKAGE CODEBLOCK