For this exercise, create a preparation specification for a custom note type named StudyFixture. Its fields, in order, are ID, Question, and Answer. Plan exactly one card template: Question on the front and Answer on the back, with ID kept out of the displayed study content. The source packet and import ledger remain the primary deliverables; no Anki note type, template, file, or import has been created here.
Separate a note from its displayed card
Use these two proposed records:
| ID | Question | Answer |
|---|---|---|
| R01 | Which letter follows A in this practice sequence? | B |
| R02 | How many items are in the list A, B, C? | Three |
Specify a UTF-8 plain-text packet with tabs separating the three fields. The table is a readable specification, not the import file. When that file is eventually prepared, confirm the actual separator and map its columns explicitly to ID, Question, and Answer in the native preview.
With an empty fixture collection and this one-template note type, the authored expectation is two notes and two cards after the first import. That count depends on the chosen template structure; “two rows” is not a universal promise of two cards. Record actual note and card counts separately after the native action.
Put the authored ID in the first field
Keep R01 stable when its Question or Answer changes. Anki's text-import manual describes first-field matching for notes of the same type and recommends keeping self-authored IDs in that first field instead of assigning them as internal GUIDs. R01 is your identifier, not an invented Anki GUID.
Prepare a revision packet containing only R01, with the same question and the revised answer “B, the next item after A.” Use the same note type, map the same first field, and explicitly choose the update-existing policy. In the isolated fixture, the expected result is still two notes: R01's Answer changes and R02 remains unchanged. Inspect the actual field values rather than accepting a total count alone.
You can also edit R01's question to clarify “the A, B, C sequence” while retaining R01. A wording edit changes content; assigning a new ID changes the identity presented for matching. The import choice matters too: updating, ignoring duplicates, and importing duplicates as new notes are different policies. Record which one was actually selected. Anki's duplicate and update instructions explain these options.
Test deck scope independently
Add a separate proposed scope test. Begin with one R01 note of type StudyFixture in a deck named Practice A, and choose Practice B as the import target. Keep the imported first field R01 and the type unchanged.
| Match scope | Question to verify |
|---|---|
| Note type | Does the existing R01 match across the two decks and update in its current deck? |
| Note type and deck | Is R01 outside the chosen target deck excluded from that duplicate match? |
Do not infer that choosing Practice B moves an existing note there. The manual describes in-place updates remaining in their current decks, with existing card scheduling retained. That is documented behavior, not an observed result from this preparation. Anki's scope guidance is the reference for the later test.
Use isolated starting states for the two scope cases. Record actual native note identifiers, first-field values, deck membership, card counts, and the selected policy before and after each import. If the second scope does not match an existing note, record the resulting native outcome rather than describing it as an update to Practice A. Confirm that template deck overrides do not confound this fixture.
Reject malformed packets before importing
Require exactly three fields per data row, a nonempty unique authored ID, and an approved question and answer. Hold missing or extra columns for correction. This is a stricter local preflight rule: the manual says short records can produce blank fields and extra content can be omitted. Previewing columns helps prevent those outcomes from becoming unnoticed content changes. Anki's file-format guidance also specifies UTF-8 text.
Keep this fixture plain text, with HTML interpretation disabled and no media references. If you later add formatting or sound, review the relevant native import settings and files separately. A readable source table does not establish that Anki imported the right fields, generated the intended cards, or retained scheduling.
Copy this note-preparation prompt
Create one complete, self-contained US-English HTML companion for “StudyFixture · Stable-ID Import Planner”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Preflight & preview; Restore authored fixture; Select initial packet; Analyze revision plan; Select revision packet. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an Anki text-import specification and acceptance ledger, without creating files, changing a collection, importing notes, or claiming study outcomes.
Use a proposed custom note type StudyFixture with fields ID, Question, Answer in that order and exactly one card template displaying Question on the front and Answer on the back. Do not display ID. Plan UTF-8 tab-separated plain text, with HTML interpretation disabled and no media.
Initial rows: R01 / Which letter follows A in this practice sequence? / B; R02 / How many items are in the list A, B, C? / Three. Under an empty isolated fixture and the one-template type, expect two notes and two cards, with actual outcomes pending.
Revision packet: R01 with the same question and Answer changed to B, the next item after A. Keep ID first and the same note type; select update-existing explicitly. Expect two notes, revised R01 and unchanged R02. Show that a later question wording edit can retain R01. Do not invent internal Anki GUIDs.
Add independent cross-deck cases: existing R01 in Practice A, target Practice B, comparing Note type and Note type plus deck match scopes. Explain that selecting a target deck does not move an in-place updated note. Record actual identifiers, fields, decks, card counts, policy and scope before and after; leave observed outcomes blank.
Require exactly three fields, nonempty unique IDs, and explicit column preview/mapping. Flag malformed rows before import. Keep documented scheduling behavior separate from measured evidence. End with checks needed to accept the native import and update.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Anki Flashcard Maker: Keep Note Identity Stable When Wording Changes
You correct an answer, import your study file again, and end up with a third note instead of updating one of the original two. The content looks almost identical, but your import has treated the revision as new material. Before making a large set of flashcards, decide which field identifies a note and which fields are allowed to change.
For this exercise, create a preparation specification for a custom note type named `StudyFixture`. Its fields, in order, are `ID`, `Question`, and `Answer`. Plan exactly one card template: Question on the front and Answer on the back, with ID kept out of the displayed study content. The source packet and import ledger remain the primary deliverables; no Anki note type, template, file, or import has been created here.
## Separate a note from its displayed card
Use these two proposed records:
| ID | Question | Answer |
| --- | --- | --- |
| R01 | Which letter follows A in this practice sequence? | B |
| R02 | How many items are in the list A, B, C? | Three |
Specify a UTF-8 plain-text packet with tabs separating the three fields. The table is a readable specification, not the import file. When that file is eventually prepared, confirm the actual separator and map its columns explicitly to ID, Question, and Answer in the native preview.
With an empty fixture collection and this one-template note type, the authored expectation is two notes and two cards after the first import. That count depends on the chosen template structure; “two rows” is not a universal promise of two cards. Record actual note and card counts separately after the native action.
## Put the authored ID in the first field
Keep R01 stable when its Question or Answer changes. Anki's [text-import manual](https://docs.ankiweb.net/manual/importing/text-files) describes first-field matching for notes of the same type and recommends keeping self-authored IDs in that first field instead of assigning them as internal GUIDs. R01 is your identifier, not an invented Anki GUID.
Prepare a revision packet containing only R01, with the same question and the revised answer “B, the next item after A.” Use the same note type, map the same first field, and explicitly choose the update-existing policy. In the isolated fixture, the expected result is still two notes: R01's Answer changes and R02 remains unchanged. Inspect the actual field values rather than accepting a total count alone.
You can also edit R01's question to clarify “the A, B, C sequence” while retaining R01. A wording edit changes content; assigning a new ID changes the identity presented for matching. The import choice matters too: updating, ignoring duplicates, and importing duplicates as new notes are different policies. Record which one was actually selected. [Anki's duplicate and update instructions](https://docs.ankiweb.net/manual/importing/text-files) explain these options.
## Test deck scope independently
Add a separate proposed scope test. Begin with one R01 note of type StudyFixture in a deck named Practice A, and choose Practice B as the import target. Keep the imported first field R01 and the type unchanged.
| Match scope | Question to verify |
| --- | --- |
| Note type | Does the existing R01 match across the two decks and update in its current deck? |
| Note type and deck | Is R01 outside the chosen target deck excluded from that duplicate match? |
Do not infer that choosing Practice B moves an existing note there. The manual describes in-place updates remaining in their current decks, with existing card scheduling retained. That is documented behavior, not an observed result from this preparation. [Anki's scope guidance](https://docs.ankiweb.net/manual/importing/text-files) is the reference for the later test.
Use isolated starting states for the two scope cases. Record actual native note identifiers, first-field values, deck membership, card counts, and the selected policy before and after each import. If the second scope does not match an existing note, record the resulting native outcome rather than describing it as an update to Practice A. Confirm that template deck overrides do not confound this fixture.
## Reject malformed packets before importing
Require exactly three fields per data row, a nonempty unique authored ID, and an approved question and answer. Hold missing or extra columns for correction. This is a stricter local preflight rule: the manual says short records can produce blank fields and extra content can be omitted. Previewing columns helps prevent those outcomes from becoming unnoticed content changes. [Anki's file-format guidance](https://docs.ankiweb.net/manual/importing/text-files) also specifies UTF-8 text.
Keep this fixture plain text, with HTML interpretation disabled and no media references. If you later add formatting or sound, review the relevant native import settings and files separately. A readable source table does not establish that Anki imported the right fields, generated the intended cards, or retained scheduling.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Keep the stable-ID source packet, revision packet, and native import record together. The useful result is a way to revise one note deliberately and verify which note changed.
Review the import plan
The HTML companion is available above for comparison with the original records. Use it beside the native Anki source and import evidence. It does not establish collection changes, card generation, scheduling, or synchronization.