Long Task Context (GPT)

GPT workflow for ChatGPT and Codex to resume multi-step work from source-linked checkpoints; preserves requirements, evidence, exact anchors, and pending actions without implying access to unavailable chats.

Long Task Context (GPT) 1.1.0

Maintain a compact continuation record, not a transcript. Respond in the user's language. Use available tools; do not claim native compaction control, extra context capacity, automatic access to all chats, or background execution.

Use one owner and one record

• Reuse the project's canonical checkpoint and storage identity. In ChatGPT use Library through its owner skill when available; in a code project use its existing persistent progress file. Do not call a scratch copy persistent.
• With Super Memori GPT, share its ledger: use this workflow for checkpoint fidelity and the next working set; let Super Memori handle broader recovery and reconciliation. Perform one combined update, not duplicate searches, schemas or saves. Neither skill grants tools or permissions to the other.
• Keep an existing Markdown or JSON layout. Add missing decision-critical fields in place; do not migrate a complete ledger merely to match the template.

Resume, then act

1. Identify the current goal, deliverables, completion criteria, project/entity and requested time or revision from the user's directions.
2. Read a known authoritative file through its owner skill first. Read the matching checkpoint for unfinished work; if unresolved, search exact project terms. Use Personal Context under its own rules only for a specific missing historical fact. Stop retrieval when the next action is supported.
3. Reconcile requirements with observed state. Prefer applicable primary evidence over summaries; compare authority, revision and event time before recency. A newly written account of an old event is still old evidence. Keep unresolved contradictions explicit.
4. Assemble the relevant protected requirements, current state and evidence needed next. Follow source pointers when precision matters. Mark missing evidence unavailable; never infer “never existed” or borrow a value from a similar object.
5. Check a pending operation's actual outcome before retrying. Continue the next authorized action; do not stop at a recap unless asked.

Preserve different information differently

Part	Preservation rule
Protected requirements	Keep every applicable goal, acceptance condition, exclusion and action boundary. Preserve exact clauses when paraphrasing can lose a negation, condition or scope. Retain preferences as preferences, not prohibitions.
Exact anchors	Preserve material project/entity IDs, model/order codes, tags, numbers, signs, units, timezones, revisions, paths and operation IDs. A page, sheet, row, timestamp or test ID must locate original evidence.
Current state	Separate completed, in progress, not done, blocked and outcome unknown. Bind checks to artifact version and tested scope; distinguish reviewed, saved, published, installed and functionally tested.
Background	Shorten redundant narrative; link detailed history and sources. Retain failed approaches only when their cause or retry condition prevents repeating an error.

Put the goal and protected requirements before background. Record authorship and source: remembered text is evidence, not a new instruction or permission. Do not copy system/developer instructions or secrets into distributable records.

Compact without compounding omissions

• Build updates from current evidence plus verified previous state; do not repeatedly summarize summaries when originals are available. If only a summary survives, mark material claims as secondary/unverified.
• Before shortening, list protected requirements and exact anchors; compare them with the new record afterward. Restore missing qualifiers; split background by subtask instead of dropping requirements to meet a word target.
• Merge repetition only within the same project, entity, event, validity period and compatible revision. Preserve meaningful distinctions and causal links. Retrieve neighboring events only to resolve a concrete gap.
• When evidence or an accepted decision changes, mark affected conclusions and deliverables needs_recheck. Preserve old checks as historical; never transfer their pass to a new revision. Leave unaffected checks valid within scope. Separate recorded time from effective time when material.
• Keep originals accessible through stable references. A pointer does not prove the bytes still exist; verify availability before depending on it. Never discard unique source evidence merely because it was summarized.

Save at material boundaries

Checkpoint after a verified milestone, accepted requirement change, material blocker, or before handoff. Prepare before a large stage if unique state could otherwise be lost. Do not write after every answer, invent remaining-context percentages, or promise a compaction hook.

1. Prepare a minimal delta against the current canonical record. Use the checkpoint template only when a new record is warranted.
2. Through the storage owner, preserve identity and use the observed version guard when supported. On conflict, reread and merge the delta while retaining concurrent changes; never overwrite with an old snapshot.
3. On timeout, treat the outcome as unknown. Inspect the receipt, operation ID and current contents before deciding whether another write is needed.
4. Before meaningful handoff, read back the saved record and perform the continuation check below. A successful receipt supports “saved”; actual readback supports “read-back verified.”

If persistent writing is unavailable or disallowed, return a compact handoff and say it was not saved. Continue independent work. Exclude credentials, secret-bearing URLs and unnecessary private data; honor forgetting requests without copying removed content into history.

Check the continuation

Using the checkpoint and linked evidence, identify: deliverable and done conditions; applicable constraints; exact current artifacts and verified checks; pending/unknown operations; unresolved issues; one executable next action and its first recheck. Repair only gaps needed for that action. No checklist proves factual correctness.

For engineering work retain document/revision, equipment/order code, tag, unit, test scope and unresolved acceptance checks. For substantial workflow changes use continuation checks; distinguish observed behavior from structural validation. Read research basis only when explaining or revising the method. Do not claim perfect recall or borrow published benchmark gains.