Project Continuity

长文方案

Internal skill ID: project-continuity.

Use the deterministic CLI in scripts/project_continuity.py. Keep raw chat content out of the continuity database; store paths, hashes, metrics, checkpoints, and lineage IDs.

Choose An Adoption Level

• baseline: use for every durable project. Keep concise project memory and open items, store large artifacts outside chat, and preserve useful Git checkpoints. SQLite and scheduled checks are optional.
• managed: use for long-running, important, automated, multi-conversation, or expensive-to-reconstruct projects. Add a continuity config, SQLite state, central registry entry, verified checkpoints, resume packets, and audits.
• observed: use when a production result can cause material harm. Add runtime health files, lineage nodes, and quality checks so results can be traced to evidence.

Use the lightest level that preserves recoverability. Upgrade when activity, operational risk, or reconstruction cost increases. One-off chats do not need registry entries.

Locate Configuration

Prefer <project-root>/config/project_continuity.json. If it is missing, read references/schema.md, create a project-specific config, then register it in the central registry.

Keep project_root pointed at the canonical source repository. If older unarchived tasks were created from a different workspace, list only those explicit paths in thread_roots; task matching may use the aliases, while Git snapshots and resume packets continue to use project_root.

Check A Task

python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py check \
  --config <project-root>/config/project_continuity.json

Interpret status strictly:

• healthy: continue and keep large outputs in files or SQLite.
• warning: tell the user the triggering metrics and confirm that a fresh checkpoint exists.
• rotate_required: finish the current safe unit, run checkpoint and audit, then tell the user to open a completely new conversation.
• error: repair missing state/config/runtime evidence before claiming continuity is ready.

Never use a handoff path that copies the old full conversation log after rotate_required. The new conversation must load the compact resume packet.

Checkpoint And Resume

Create a checkpoint before risky edits, thread rotation, or archival:

python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py checkpoint \
  --config <config> --reason manual

In a fresh conversation, load and verify the latest packet:

python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py resume \
  --config <config>
python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py audit \
  --config <config>

Then read the listed project-memory files, inspect git status, and verify current runtime evidence. Do not replay completed operations.

Project-Level Acceptance

Managed and observed projects should expose one deterministic acceptance command that combines continuity status, checkpoint hash, audit result, Git state, required recovery files, denied tracked paths, and project runtime health. Run it before rotation and again in the recovered conversation.

Keep operator and production schedules separate. A server business cron may publish a secret-free heartbeat for the acceptance command to read; it must not depend on the local Codex state database or run the continuity CLI. Remote probes must use fixed, documented paths and pass credential file paths to their client process without reading credential contents.

Safe Recovery Reads

• Read only paths listed in the resume packet and the specific Git-tracked files needed for the task.
• Never recursively search hidden or untracked locations during recovery. Denylist .deploy, .env*, private-key files, credential stores, and session files.
• Put secret-free deployment metadata in a tracked runbook or entrypoint and list it in context_files; do not discover connection details with a broad rg or find.
• If tool output contains a private-key block or a credential value, stop, do not reproduce it, rotate the affected credential, archive the task as unsafe, and restart recovery in a fresh task.

Scheduled Guard

Register each managed or observed project once, then schedule check-all --notify through one central Codex automation. The CLI deduplicates identical reminders and writes a checkpoint when warning state changes.

python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py register \
  --config <config> --registry <registry>
python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py check-all \
  --registry <registry> --notify

Default to one check per day. A two-day cadence is acceptable for low-activity projects; increase frequency only during unusually active work. The automation should archive its own healthy run and leave only warning, rotate_required, or error runs visible.

Version And Install

Keep the editable skill source in GitHub. Treat the installed copy under ~/.codex/skills as a deployment target: edit the source, validate it, run tests, sync the installed copy, then commit and push. Exclude runtime SQLite files, session logs, generated checkpoints, and secrets from the skill repository.

Purge Safely

Always preview managed data first:

python3 ~/.codex/skills/project-continuity/scripts/project_continuity.py purge-plan \
  --config <config> --scope conversation --conversation-id <id>

Run purge only after the user explicitly confirms the exact token returned by purge-plan. Project purge removes the managed continuity runtime and disables its registry entry. It does not remove source code, Codex cloud chats, Saved Memory, Git remotes, deployed servers, or backups; report those remaining scopes explicitly.

Data Discipline

• Raw tool output larger than a concise answer belongs in an artifact, not chat.
• Every checkpoint records project_id, conversation_id, hashes, git state, context files, health files, and lineage edges.
• Project acceptance reports should be generated artifacts and must contain summaries, IDs, hashes, counts, and statuses only.
• Generated Wiki/context packs must point to exact evidence paths and remain small.
• Do not store credentials, cookies, private keys, seed phrases, access tokens, or raw private conversations.
• Read references/schema.md when creating a config, changing thresholds, or extending the lineage model.