This preparation uses native Obsidian Bases Kanban, which the current Kanban help page lists as requiring Obsidian 1.14 or later. The installed version is unknown here. Keep community plugin instructions and older board formats separate; their behavior has not been established for this fixture.
Start with three notes whose contents you can inspect
Plan a folder named Practice with these Markdown notes:
| File | Stored status | Body text |
|---|---|---|
note-a.md |
Draft | Practice A outline. |
note-b.md |
Review | Practice B check. |
note-c.md |
No status property | Practice C pending. |
The native files and .base configuration have not been created. For a later test, filter globally with both file.inFolder("Practice") and file.ext == "md", then group the Kanban view by note.status. Do not add an unrelated view filter to this minimal fixture.
The expected initial membership is A in Draft, B in Review, and C in None. Missing status is not an authored Draft value. Record file identity and actual frontmatter alongside the view so you can distinguish absence from a deliberate setting.
Check the stored field after a proposed move
In the later native property-grouped view, move A from Draft to Review. Obsidian documents moving a Markdown card between such columns as updating the grouped note property. See the native card-movement description.
For this fixture, the expected stored change is A's status becoming Review. Inspect the actual frontmatter, reopen the view, and verify A's membership. Also compare the file identity and body text with the original record: “Practice A outline.” should remain the authored body for this test. That preservation is an acceptance condition to check, not an observed result here.
| Evidence field | Expected or pending entry |
|---|---|
| File before and after | The same Practice/note-a.md; verify actual identity |
| Stored property before | status: Draft |
| Proposed stored property after | status: Review |
| Body after | Compare with Practice A outline. |
| Reopened view | Verify actual Review membership |
| Work completed | Not established by the property move |
A status change records classification. It does not establish that someone reviewed the outline, approved it, or enforced a work-in-progress limit. Keep any real completion evidence outside this small view test.
Compare a formula that displays the same value
Prepare an alternative view with formula stage defined by the expression note.status, then group by formula.stage. A and B may show the same Draft and Review values, but the grouping is computed rather than a stored note field.
The native help says formula grouping does not allow moving cards or columns or creating notes from those columns. Identical labels therefore do not imply identical editing behavior. Obsidian's formula-grouping restriction is the contract to confirm in the actual version. Manage visibility separately and inspect the stored status through the note; do not describe a formula label as a writable field.
Likewise, a display name such as Stage is presentation. It does not rename the stored status key used by this fixture's filter or formula. The Bases syntax reference distinguishes note properties, formula properties, and display names.
Find the note hidden by group order
Suppose the planned property view sets groupOrder to Draft and Review only. C's None group is hidden, but C remains a source note with no status. Hidden does not mean deleted, finished, or assigned to Review.
The syntax reference says a listed group order also controls visibility and uses YAML null to include files lacking a grouped value. For this fixture, compare Draft/Review visibility with Draft/Review/null visibility. Use the actual configuration representation, rather than assuming the displayed word None is a stored status string. See group-order syntax.
Use a source-versus-view ledger: all three notes remain in the proposed filtered dataset, while the visible groups differ. If you later add a view filter, review it too: global and view filters combine with AND. That is separate from hiding a group.
Keep folder grouping outside this exercise. The native help describes file.folder movement as moving the file itself, a different mutation from editing status. Do not quietly substitute it to make a computed board draggable.
Copy this property-and-view prompt
Prepare a native Obsidian Bases Kanban specification and acceptance ledger. Do not create files, install tools or plugins, move cards or files, delete notes, sync a vault, or claim a tested board. Installed Obsidian version is unknown; current native Kanban documentation requires 1.14 or later.
Propose three files in Practice. For note-a.md, use status Draft and body "Practice A outline." For note-b.md, use status Review and body "Practice B check." For note-c.md, omit status and use body "Practice C pending." Use a global AND filter for file.inFolder("Practice") and file.ext == "md". Group the property view by note.status. Expect A Draft, B Review, C None, with actual results pending.
Plan a later move of A to Review. Record actual file identity, stored status, body, and reopened view. Expected status becomes Review; do not equate that move with completed work or promise body preservation without inspection.
Compare formula stage defined by note.status and grouping by formula.stage. Explain that the same displayed values do not make formula grouping writable. Keep a display name Stage separate from the stored status key. Compare groupOrder Draft/Review with Draft/Review/null: C may be hidden but remains a source note, and null includes missing values rather than storing the word None.
Keep file.folder grouping and file movement out of scope. Explain global versus view filters if additional filters are proposed. Leave native app/edit/reopen outcomes blank and finish with the evidence needed to approve property, formula and visibility behavior.
Keep the native notes, .base configuration, and edit/reopen evidence together. The board becomes understandable when you can tell whether an action changes a stored value, computes a label, or only changes what you see.
Optional: keep the comparison in NOS
If you separately prepare an HTML summary of the three-note fixture and acceptance ledger, NOS can save and render that HTML. Use it beside the native Obsidian records. Native property edits, formula behavior, vault files, and synchronization require their own verification.
Explore NOS to keep a prepared HTML property-and-view comparison readable while the native board checks are pending.