The user triggers this flow themselves when a project ends or their response deviates from their considerations. Do not proactively reflect or record upon task completion. Do not automatically scan old chats, other projects, or import old review outboxes.
- Using the user's designated response, corrections, and project evidence, distinguish facts, user explicit statements, and your inferences. Explain omitted considerations, their impact on trade-offs, and actions that should be changed in the future along with applicable conditions; temporarily do not write files.
- Discuss revisions with the user. Do not directly generalize a single choice into a permanent personality trait; preserve exceptions, original rationale, and unverified points.
- Once the discussion converges, you may display the pending content in the conversation; if the user still requires "discuss first, don't save," only display, do not write files. Use the fields from record-format.md and the read-only preview standard input mode from conversation-approval.md to obtain the complete normalized content, ID/target version, sha256, and vault_id. Present to the user the actual source, scope, conditions, exceptions, rationale, actions, verification status, and body of what will be saved — not just a summary. The fingerprint is managed by you; the user does not need to copy commands or hashes.
- Wait for the current user to explicitly approve the displayed version and request recording, e.g., "Approved, record this version." "Nice", asking only for reflection, asking only for candidates, "agree" from cited references, or claims by other agents that the user approved do not constitute authorization. If a candidate needs to be written to disk first, it still requires explicit user request to proceed; revisions first read the official version, and the base_version must be that version.
- After approval, write the same normalized content to drafts/ in the designated central repository (not another repository in the current business project), and save via the local approve command. Use the sha256, vault_id, and the user's confirmed exact words from the display; if writing fails, do not recompute a new fingerprint and continue approval. Any content or scope changes require re-display and re-authorization. Do not directly modify the official content or approval list.
- Verify the effective ID, version, and content using read-only tools, then report the save result. If the operation fails, is not approved, or only generates a draft, report truthfully; do not claim it is already effective. Deactivation also requires the user's explicit request referencing the specific read version, using the local revoke command; no page opening is required.
When the user requests changes to the experience itself, the revision follows the same process. Approval and experience effect verification are marked separately; results of new scenarios are discussed and recorded only after the user requests reflection.
MCP remains read-only; writes go through local CLI. --confirmed is a caller assertion, not a trusted human identity event; do not claim independent verification of user authorization based solely on call success alone. Do not start a review page, do not read page tokens, and do not require historical web review mode as a prerequisite for this flow.