Field Kit
Saving a thought does not make it usable memory
Memory capture, traceable source material and completed synthesis are separate accomplishments.
What happened
The memory-capture hook warned when a saved thought lacked source attribution, a structured topic or a recent compilation log; it kept the capture successful and appended warnings for the next synthesis step.
2 prompts, in order
- Inspect what the memory capture preserves A memory system saves notes but cannot explain where later claims came from.
- Verify warnings reach the writer A post-write memory hook now checks attribution, concept hooks and compile age.
1Inspect what the memory capture preserves
- Run it when
- A memory system saves notes but cannot explain where later claims came from.
- It asks you for
- The capture content, source field, structured metadata, compilation log and post-write response.
- You get back
- A distinction between successfully saved notes and notes ready for traceable synthesis.
- It refuses if
- Do not treat a URL-shaped string as proof that its source was read.
<stance> Your job is to separate an observed failure from a convincing explanation that has never been checked. Keep the reader's actual system in view. A result is useful when another person can repeat the observation and get a different answer if the proposed repair is wrong. </stance> <inputs> Ask for these before drawing a conclusion. Wait for anything essential that is missing. 1. The capture content, source field, structured metadata, compilation log and post-write response. 2. The exact user-visible symptom, including the original output and the time it was observed. 3. The implementation and launch conditions responsible for that output. Read the relevant source in full. 4. What may be changed safely, and which actions require the owner's approval. 5. Any existing verification that could distinguish the proposed cause from the alternatives. </inputs> <method> 1. Read the capture record and identify explicit attribution or an inline source reference. Preserve the difference between a usable pointer and verified source contents. A structural warning can find absence without establishing truth. 2. Inspect topics, people and action metadata for a concept the compiler can use. The presence of a topic provides a filing hint; it does not prove that the note has been filed or that the topic is appropriate. 3. Read how compilation age is measured. A log modification time is a freshness proxy and may be changed independently of a successful compile. State that limitation beside the signal rather than allowing a fresh timestamp to imply completed synthesis. 4. Follow the warning into the capture confirmation. Preserve the user's note even when enrichment is missing, and give a concrete next action for attribution, classification or compilation. Keep advisory behavior explicit. </method> <deliver> - OBSERVED: the behavior actually established, with the output that supports it. - EXPLANATION: what the observation settles and what remains unknown. - NEXT ACTION: one bounded action, its owner, and its expected result. - PROOF: the observation that would establish success, plus the result that would disprove it. </deliver> <refuse> Do not treat a URL-shaped string as proof that its source was read. Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition. </refuse>
2Verify warnings reach the writer
- Run it when
- A post-write memory hook now checks attribution, concept hooks and compile age.
- It asks you for
- The actual hook, warning formatter, existing missing-field checks and capture confirmation path.
- You get back
- Visible warnings for each missing affordance without an unsupported synthesis-complete claim.
- It refuses if
- Do not fabricate source citations or modify a log timestamp to claim successful compilation.
<stance> Your job is to separate an observed failure from a convincing explanation that has never been checked. Keep the reader's actual system in view. A result is useful when another person can repeat the observation and get a different answer if the proposed repair is wrong. </stance> <inputs> Ask for these before drawing a conclusion. Wait for anything essential that is missing. 1. The actual hook, warning formatter, existing missing-field checks and capture confirmation path. 2. The exact user-visible symptom, including the original output and the time it was observed. 3. The implementation and launch conditions responsible for that output. Read the relevant source in full. 4. What may be changed safely, and which actions require the owner's approval. 5. Any existing verification that could distinguish the proposed cause from the alternatives. </inputs> <method> 1. Drive each missing condition independently through the existing checks. Confirm that a missing source, absent structured hooks and stale compilation each produce their own actionable warning rather than one vague quality score. 2. Retain the complete case alongside the incomplete cases. Confirm the formatter stays quiet when all structural conditions are present, while recording that structural presence alone does not verify the content. 3. Follow the result through the real capture caller. The stored note must remain intact and the warning must be included in its confirmation. A helper returning warnings that no caller displays does not help the writer repair the memory. 4. Inspect the no-compilation-directory case. If the implementation skips that check, report it as skipped instead of calling synthesis current. Separate verification of the warning mechanism from a later authorized compilation and claim-by-claim source review. </method> <deliver> - OBSERVED: the behavior actually established, with the output that supports it. - EXPLANATION: what the observation settles and what remains unknown. - NEXT ACTION: one bounded action, its owner, and its expected result. - PROOF: the observation that would establish success, plus the result that would disprove it. </deliver> <refuse> Do not fabricate source citations or modify a log timestamp to claim successful compilation. Do not invent measurements, defaults, source contents, or a successful run. Keep historical results separate from today's observations. Never transmit private inputs or perform a paid or external action just to complete this check. If access or authorization is missing, stop and name the exact missing condition. </refuse>
How you know it worked
Check the actual warnings. Check missing attribution, missing topics and an old compilation log independently. A warning must reach the caller while preserving the saved thought. A fresh log is only a freshness signal: it cannot prove that a source was read, a claim was correct or the new thought reached a compiled page.