armarium 0.1.0__tar.gz

armarium-0.1.0/.gitignore

@@ -0,0 +1,10 @@
+.scratch/
+.DS_Store
+
+.venv/
+__pycache__/
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+dist/
+*.egg-info/

armarium-0.1.0/AGENTS.md

@@ -0,0 +1,17 @@
+# Repository workflow
+
+- Never commit or push directly to `main`.
+- Make all changes, including planning and documentation, on a working branch
+  and submit them through a pull request.
+- The user reviews and merges pull requests; do not merge them on the user's behalf
+  without explicit instruction.
+
+# Testing conventions
+
+- Tests for a source module `X.py` belong in `test_X.py`.
+- Cover every class, function, and method with dedicated tests, including private
+  helpers and properties.
+- Organize tests into classes named for the class, function, or method under test
+  (for example, `TestParseWikilink` or `TestResultFailed`).
+- Minimize redundant test code aggressively with `pytest.mark.parametrize`; share
+  a test body when cases exercise the same behavior with different inputs.

armarium-0.1.0/CHANGELOG.md

@@ -0,0 +1,15 @@
+# Changelog
+
+## Unreleased
+
+## 0.1.0 (2026-09-30)
+
+- Add `armarium init` for creating standalone vaults.
+- Add `armarium add` subcommands for campaigns, Content, Clues, Sessions, Players,
+  Notes, and Transcripts, using vault-local templates and conventions.
+- Add `armarium validate` for records, directories, and vaults, with checks for
+  schemas, Markdown structure, wikilinks, and relationships between records.
+- Add shared setting content and campaign-specific records, with Obsidian Bases
+  views for clues and session preparation.
+- Add a starter vault and a two-campaign example vault.
+- Add the MIT license and changelog-driven release automation.

armarium-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 William J. Bradshaw
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

armarium-0.1.0/PKG-INFO

@@ -0,0 +1,98 @@
+Metadata-Version: 2.5
+Name: armarium
+Version: 0.1.0
+Summary: Create and validate Armarium Markdown vaults
+Project-URL: Homepage, https://github.com/willbradshaw/armarium
+Project-URL: Repository, https://github.com/willbradshaw/armarium
+Project-URL: Issues, https://github.com/willbradshaw/armarium/issues
+Project-URL: Changelog, https://github.com/willbradshaw/armarium/blob/main/CHANGELOG.md
+Author: Will Bradshaw
+License-Expression: MIT
+License-File: LICENSE
+Requires-Python: >=3.14
+Requires-Dist: jsonschema[format]<5,>=4.23
+Requires-Dist: markdown-it-py<4,>=3
+Requires-Dist: pyyaml<7,>=6
+Requires-Dist: referencing<1,>=0.35
+Provides-Extra: dev
+Requires-Dist: build<2,>=1; extra == 'dev'
+Requires-Dist: mypy; extra == 'dev'
+Requires-Dist: pytest>=8; extra == 'dev'
+Requires-Dist: ruff==0.16.8; extra == 'dev'
+Requires-Dist: types-jsonschema; extra == 'dev'
+Requires-Dist: types-pyyaml; extra == 'dev'
+Description-Content-Type: text/markdown
+
+# Armarium
+
+A system-general starter for tabletop roleplaying knowledge bases in Obsidian.
+
+See [vaults/example](vaults/example) for a fleshed-out toy vault that follows and
+demonstrates this repository's conventions.
+
+## Create a vault
+
+With Python 3.14+ and [uv](https://docs.astral.sh/uv/guides/tools/), install
+Armarium from this checkout and create a vault:
+
+```sh
+uv tool install .
+armarium init ../my-vault
+```
+
+If `armarium` is not on your PATH, run `uv tool update-shell` and restart your
+terminal. To reinstall after updating this checkout, use
+`uv tool install --reinstall-package armarium .`.
+
+Open the new folder in Obsidian and edit
+`campaigns/campaign_1/reference/Campaign.md`. See [Creating a vault](docs/init.md)
+for details.
+
+Add campaigns and records with `armarium add`; see
+[Adding to a vault](docs/add.md).
+
+Requires Obsidian **1.13.7+** with **Bases** and
+[Frontmatter Markdown Links](https://github.com/mnaoumov/obsidian-frontmatter-markdown-links)
+enabled.
+
+## Layout
+
+| Folder | Purpose |
+| --- | --- |
+| `content/` | Shared setting content. |
+| `campaigns/campaign_1/` | Campaign content, clues, sessions, and reference material. |
+| `reference/` | Templates, type descriptions, schemas, statuses, and shared reference material. |
+| `assets/` | Maps, images, and handouts. |
+
+Use [`armarium add`](docs/add.md#adding-a-record) or copy a file from
+`reference/templates/` to create a record. [Records](docs/record.md)
+describes what every record shares and [Types](docs/type.md) the fields, body
+and rules of each type.
+
+The starter is preconfigured for a single campaign. The example includes two
+campaigns sharing setting Content, with independent campaign state and combined
+Clue and appearance lists. [Vault layout](docs/vault.md) states the full required
+skeleton and where each record type lives.
+
+`.obsidian/` holds the settings the records rely on and is part of the vault;
+only Obsidian's workspace files are ignored. `.scratch/` is ignored working
+space; `.gitkeep` files preserve empty directories in Git. The copied vault can
+be its own Git repository.
+
+For schema integration and testing, see [Schema development](docs/schemas.md).
+
+Planned work is tracked in the [issues](https://github.com/willbradshaw/armarium/issues).
+
+MIT licensed. See the [changelog](CHANGELOG.md) and [release process](docs/releases.md).
+
+## Validate records
+
+Validate a record or a whole vault:
+
+```sh
+armarium validate path/to/record.md
+armarium validate ../my-vault
+```
+
+See [Validation](docs/validate.md) for the command's options, what is checked
+and how findings are reported.

armarium-0.1.0/README.md

@@ -0,0 +1,73 @@
+# Armarium
+
+A system-general starter for tabletop roleplaying knowledge bases in Obsidian.
+
+See [vaults/example](vaults/example) for a fleshed-out toy vault that follows and
+demonstrates this repository's conventions.
+
+## Create a vault
+
+With Python 3.14+ and [uv](https://docs.astral.sh/uv/guides/tools/), install
+Armarium from this checkout and create a vault:
+
+```sh
+uv tool install .
+armarium init ../my-vault
+```
+
+If `armarium` is not on your PATH, run `uv tool update-shell` and restart your
+terminal. To reinstall after updating this checkout, use
+`uv tool install --reinstall-package armarium .`.
+
+Open the new folder in Obsidian and edit
+`campaigns/campaign_1/reference/Campaign.md`. See [Creating a vault](docs/init.md)
+for details.
+
+Add campaigns and records with `armarium add`; see
+[Adding to a vault](docs/add.md).
+
+Requires Obsidian **1.13.7+** with **Bases** and
+[Frontmatter Markdown Links](https://github.com/mnaoumov/obsidian-frontmatter-markdown-links)
+enabled.
+
+## Layout
+
+| Folder | Purpose |
+| --- | --- |
+| `content/` | Shared setting content. |
+| `campaigns/campaign_1/` | Campaign content, clues, sessions, and reference material. |
+| `reference/` | Templates, type descriptions, schemas, statuses, and shared reference material. |
+| `assets/` | Maps, images, and handouts. |
+
+Use [`armarium add`](docs/add.md#adding-a-record) or copy a file from
+`reference/templates/` to create a record. [Records](docs/record.md)
+describes what every record shares and [Types](docs/type.md) the fields, body
+and rules of each type.
+
+The starter is preconfigured for a single campaign. The example includes two
+campaigns sharing setting Content, with independent campaign state and combined
+Clue and appearance lists. [Vault layout](docs/vault.md) states the full required
+skeleton and where each record type lives.
+
+`.obsidian/` holds the settings the records rely on and is part of the vault;
+only Obsidian's workspace files are ignored. `.scratch/` is ignored working
+space; `.gitkeep` files preserve empty directories in Git. The copied vault can
+be its own Git repository.
+
+For schema integration and testing, see [Schema development](docs/schemas.md).
+
+Planned work is tracked in the [issues](https://github.com/willbradshaw/armarium/issues).
+
+MIT licensed. See the [changelog](CHANGELOG.md) and [release process](docs/releases.md).
+
+## Validate records
+
+Validate a record or a whole vault:
+
+```sh
+armarium validate path/to/record.md
+armarium validate ../my-vault
+```
+
+See [Validation](docs/validate.md) for the command's options, what is checked
+and how findings are reported.

armarium-0.1.0/docs/add.md

@@ -0,0 +1,170 @@
+# Adding to a vault
+
+`armarium add` creates [campaigns](#adding-a-campaign) and [records](#adding-a-record)
+in an existing [vault](vault.md) using its local templates and conventions, then
+[validates the result](#templates-and-validation). For example:
+
+```sh
+armarium add campaign --vault ../my-vault
+armarium add content "Port Briselle" --subtype Location --vault ../my-vault
+armarium add session --campaign 1 --vault ../my-vault
+```
+
+For a new vault, start with [`armarium init`](init.md).
+
+## Shared behavior
+
+All commands share rules for [vault selection](#choosing-a-vault-and-destination),
+[campaign selection](#choosing-a-campaign) and [templates and
+validation](#templates-and-validation).
+
+### Choosing a vault and destination
+
+Pass `--vault PATH` to select a vault's root directory, using an absolute path or a path
+relative to your current directory. Omit it to discover the vault from your current
+directory when running anywhere inside it.
+
+Records go in the selected vault's [declared directory](vault.md#where-records-live) for
+their type and [campaign scope](#choosing-a-campaign), rather than directly in the
+current directory. Existing records and campaigns are never overwritten.
+
+### Choosing a campaign
+
+While inside a [campaign directory](campaign.md#directory) or any descendants, new
+records created with `armarium add` are added to that campaign. Use `--campaign N` to
+select another existing campaign. Selecting a different vault does not inherit the
+current campaign.
+
+Outside a campaign directory, [Content](#content) and [Notes](#notes) default to shared
+scope; [Players](#players), [Sessions](#sessions) and [Clues](#clues) require
+`--campaign`. [Transcripts](#transcripts) always take their campaign from the selected
+Session. [`add campaign`](#adding-a-campaign) creates a new campaign.
+
+### Templates and validation
+
+Initial values come from the vault's local [templates](record.md#anatomy), and validation
+uses its [schemas](record.md#types-statuses-and-schemas). Edit a template to change
+defaults, or edit the new record afterward.
+
+A new [record](record.md) must pass [schema, link and contextual
+checks](validate.md#checks). Failed writes, interruptions and record-validation failures
+remove the new record. Each command then [validates the whole vault](validate.md#scope);
+failure exits with status 1 and retains the valid new record for inspection. Campaign
+creation removes partial campaigns on write failure, but retains them on validation
+failure.
+
+## Adding a campaign
+
+Add a [campaign](campaign.md):
+
+```sh
+armarium add campaign --vault ../my-vault
+```
+
+The new number is one greater than the largest existing campaign number; `--number N`
+chooses an unused positive number explicitly.
+
+Campaign and Clues templates supply the initial records. Their `campaign_1` and `C-1-`
+clue ID placeholders are updated to the new number; other text is preserved. Players,
+sessions and content are not copied from existing campaigns.
+
+## Adding a record
+
+[Content](#content), [Players](#players) and [Notes](#notes) take a name, which becomes
+the filename. Names may contain spaces; omit `.md`.
+
+[Sessions](#sessions) and [Clues](#clues) use numbered filenames. By default, the number
+is one greater than the largest existing number of that type in the campaign, including
+archives. Use `--number N` to choose an unused number within the type's range.
+
+[References to existing records](record.md#links) must resolve uniquely; use
+vault-relative paths when names are ambiguous.
+
+### Content
+
+```sh
+armarium add content "Port Briselle" --subtype Location --vault ../my-vault
+armarium add content "Mira" --subtype PC --campaign 1 --player Alex --vault ../my-vault
+```
+
+Use `--subtype NPC|PC|Location|Faction|Object|Lore` to select the [Content
+subtype](type.md#content). Required nullable subtype fields start empty unless set in
+the template. PCs need an existing [Player](#players), supplied with `--player` or in
+the template.
+
+Shared records start without [campaign state](campaign.md#state). Campaign-specific
+records get a `campaign_N` block, where `N` is the selected campaign number; Objects
+also get `held_by` in that block.
+
+### Sessions
+
+```sh
+armarium add session --campaign 1 --vault ../my-vault
+```
+
+Creates a [Session](type.md#session), `S-N-NNN.md`, with the campaign link and session
+number filled in. Session numbers range from 1 to 999.
+
+### Players
+
+```sh
+armarium add player "Alex" --campaign 1 --vault ../my-vault
+```
+
+The standard template creates an unassigned [Player](type.md#player) with `plays: []`.
+Configured links must target shared or same-campaign PCs. Use [add content](#content) to
+create a PC linked to the new Player; creating a Player does not change PCs or
+backlinks.
+
+### Notes
+
+```sh
+armarium add note "Working ideas" --vault ../my-vault
+armarium add note "Session prep" --campaign 1 --vault ../my-vault
+```
+
+Copies the local [Note](type.md#note) template, including its metadata and body. An
+empty body is valid.
+
+### Clues
+
+```sh
+armarium add clue --campaign 1 --vault ../my-vault --text 'The gate is locked from within.'
+```
+
+Creates a [Clue](type.md#clue), `C-N-NNNN.md`. Clue numbers range from 1 to 9999.
+
+Supply nonblank `--text`, or omit it to use nonblank text from the local template.
+`armarium add clue --vault ../my-vault --help` shows the discovered default text, or
+indicates that `--text` is required when the template text is blank.
+
+Text goes in [frontmatter](record.md#anatomy). Its [wikilinks](record.md#links) must
+target shared or same-campaign [Content](#content). `subjects` is derived from those
+targets without duplicates, or `[]` for unlinked text. Template status, session fields
+and the Sessions section/Base embed are preserved.
+
+### Transcripts
+
+```sh
+armarium add transcript S-1-001 --body-file recorded-speech.md --vault ../my-vault
+```
+
+Select an existing [Session](#sessions) by name or vault-relative path. Its campaign and
+identity determine the [Transcript](type.md#transcript) destination, `S-N-NNN
+Transcript.md`. No Session is selected automatically.
+
+`--body-file` is required and reads UTF-8 Markdown without frontmatter:
+
+```markdown
+## Arrival
+
+- [GM] The door opens.
+- [Player] Who is there?
+```
+
+Follow the [Transcript body format](type.md#body-7): titled level-two sections, each
+containing one bullet list of attributed, single-paragraph utterances. The supplied body
+replaces the template's instructional sample. The command imports already-formatted text
+without transcribing audio, editing speech or changing the source file or Session. Body
+grammar and the local schema are checked before creating the file; link and contextual
+checks follow.

armarium-0.1.0/docs/campaign.md

@@ -0,0 +1,46 @@
+# Campaigns
+
+Each [vault](vault.md) holds one or more **campaigns**, each in its own directory
+`campaigns/campaign_N/` (with `N` a positive integer). Each campaign describes a series of TTRPG [sessions](type.md#session) in the vault's setting, along with their shared context and metadata.
+
+## Directory
+
+```text
+campaigns/campaign_N/
+  clues/                  Clue records, C-N-NNNN.md
+  content/                Content records specific to this campaign
+  notes/                  Note records specific to this campaign
+  reference/
+    Campaign.md           the campaign overview, a Reference record
+    indexes/
+      Clues.md            the clue index, a Reference record
+    players/              Player records
+  sessions/               Session records, S-N-NNN.md
+    transcripts/          Transcript records, S-N-NNN Transcript.md
+```
+
+The starter vault ships `campaign_1`. Use [`armarium add campaign`](add.md#adding-a-campaign)
+to add another.
+
+## State
+
+[Content](type.md#content) records carry `campaign_N` blocks in their frontmatter describing their campaign-related state:
+
+```yaml
+campaign_1:
+  first_session: "[[S-1-001]]"
+  last_session: "[[S-1-002]]"
+campaign_2:
+  first_session:
+  last_session:
+```
+
+A block's `first_session` and `last_session` are both null until the record
+first appears in that campaign, and then both link to the earliest and latest
+Session of that campaign in the record's Appearances. `N` must be an existing
+campaign, and a record under `campaigns/campaign_N/content` may carry only that
+campaign's block; shared Content may carry a block for any campaign.
+
+A Content record with the Object subtype has an additional field in its campaign blocks: `held_by`. This is null before the object enters play; then a link to a Content entry denoting the PC, NPC or Faction holding the object, or a list thereof for shared possession; then `GONE` if the object has left play.
+
+In addition to the `campaign_N` blocks, a Content entry must also describe its subject's appearances in each campaign in its Appearances section; see [Content](type.md#content) for more details.

armarium-0.1.0/docs/init.md

@@ -0,0 +1,22 @@
+# Creating a vault
+
+```sh
+armarium init ../my-vault
+```
+
+`armarium init PATH` initializes a new vault in a fresh directory by copying the
+[starter vault](../vaults/starter/). `PATH` must be a nonexistent directory;
+existing files and directories (even empty ones) are refused, as are symbolic
+links. Missing parent directories are automatically created. If copying fails or
+is interrupted, the partially created vault is removed safely. After copying
+completes, the new vault undergoes validation before success is reported.
+
+Use `armarium init --force PATH` to replace an existing directory and **all its
+contents** with the starter vault. Files and symbolic links are still refused.
+The replacement is copied before the old directory is removed, so a copy failure
+leaves the existing directory intact.
+
+`init` does not initialize Git or install Obsidian plugins. After completion,
+open the new vault in Obsidian and enable the plugins listed in
+[the README](../README.md) before editing. After initialization, the vault can be
+moved or placed in its own Git repository.

armarium-0.1.0/docs/record.md

@@ -0,0 +1,73 @@
+# Records
+
+Every Markdown file in a [vault](vault.md) is a record: YAML frontmatter that
+declares its type, followed by a Markdown body. What every record shares is
+below; each type's fields, body and rules are documented in [Types](type.md).
+
+## Anatomy
+
+```markdown
+---
+type: "[[types/Content]]"
+subtype: NPC
+summary: Harbour pilot who witnesses petitions.
+aliases: [Mara]
+campaign_1:
+  first_session: "[[S-1-001]]"
+  last_session: "[[S-1-002]]"
+---
+## Notes
+Mara holds a seat for the eastern approaches. ^seat
+```
+
+**Frontmatter** is a YAML mapping between the opening and closing `---` lines.
+Keys must be unique strings and values representable in JSON, so dates are
+written as `YYYY-MM-DD` strings. A record without frontmatter has no type and
+is invalid. Fields beyond a type's schema are allowed on every type.
+
+**`type`** is the one field every record must have: a canonical
+[wikilink](#links) to the record's Type record, `[[types/Content]]` or
+`[[Content]]`, with no alias or anchor. The last path segment names the type,
+and `reference/types/Content.md` must exist.
+
+**The body** is everything after the closing `---`: CommonMark with tables,
+as Obsidian renders it. Headings divide it into sections, nested by level; a
+paragraph or list item may end in an Obsidian block id (`^seat`). Each type
+fixes which headings its body must have; the rest is free Markdown.
+
+**Templates** in `reference/templates/` are starting points, not records:
+their placeholder values need not follow the rules. Copy one to start a record.
+
+## Links
+
+Records link to each other with Obsidian
+[internal links](https://help.obsidian.md/links): `[[Quay Nine]]`,
+`[[Quay Nine|the quay]]`, `[[S-1-002#Events]]`, `[[The Bell Accord#^hearing]]`,
+`![[…]]` to embed. Armarium adds these rules:
+
+- Every link must resolve to exactly one file. A target matches any trailing
+  part of a file's path, case-insensitively and with `.md` optional, so the
+  shortest spelling that is unique is enough; when two files share a name,
+  spell enough of the path to tell them apart.
+- A heading or block anchor must exist in the linked record. Anchors on files
+  that are not records (`![[reference/views/clue-index.base#Active]]`) are
+  not validated.
+- In frontmatter a link must be **canonical**: quoted, `"[[target]]"`, with no
+  alias or anchor. A frontmatter field may not name the same file twice.
+- Inside a Markdown table, a `|` within a link is written `\|` to avoid
+  splitting the link between cells.
+
+## Types, statuses and schemas
+
+The type system lives in `reference/`:
+
+- A **Type** record in `reference/types/` defines a type: its name is the
+  filename, and its `directories` field says
+  [where its records live](vault.md#where-records-live).
+- A **schema**, `reference/schemas/<type>.schema.json`, describes each record
+  of the type as `{frontmatter, body}` in JSON Schema draft 2020-12: the
+  frontmatter as parsed, the body as one string. Every Type has a schema and
+  every schema a Type.
+- A **Status** record in `reference/statuses/` defines a lifecycle state for
+  one type, named in `applies_to`. A record's `status` must be a Status whose
+  `applies_to` is the record's type. The six shipped statuses apply to Clues.

armarium-0.1.0/docs/releases.md

@@ -0,0 +1,20 @@
+# Releases
+
+Every PR updates [CHANGELOG.md](../CHANGELOG.md), normally under `Unreleased`.
+
+To prepare a release, update `version` in [pyproject.toml](../pyproject.toml),
+rename the `Unreleased` heading to `VERSION (YYYY-MM-DD)`, and add a fresh
+`Unreleased` heading above it. Merge the PR to create a draft GitHub release
+whose text comes from that version's changelog section. The draft targets the
+commit that triggered the workflow. The `draft-release` workflow can also be
+run manually to retry draft creation.
+
+Changes to `pyproject.toml` or `CHANGELOG.md` trigger the workflow. It skips
+draft creation unless the changelog has a versioned heading matching the package
+version, and skips versions that already have a GitHub release. PR titles do
+not affect release creation.
+
+Review and publish the draft on GitHub. The `publish` workflow checks out the
+release tag, checks that it matches the package version, runs lint, type checks,
+tests and vault validation, then builds and publishes to PyPI. Tags use the
+package version without a `v` prefix, for example `0.1.0`.

armarium-0.1.0/docs/schemas.md

@@ -0,0 +1,52 @@
+# Schema development
+
+For contributors changing and testing schemas. Record authoring rules
+live in the vault's `reference/types/` Type records.
+
+## Input and schema selection
+
+Draft 2020-12 schemas validate `{frontmatter, body}`: parsed frontmatter and the
+Markdown body. Dates are represented as ISO date strings; Session `date` accepts
+`YYYY-MM-DD` or null. Custom frontmatter fields are allowed.
+
+Each supported `type` has a schema in the vault's `reference/schemas/` directory:
+
+| `type` | Schema |
+| --- | --- |
+| `[[types/Content]]` | `content.schema.json` |
+| `[[types/Clue]]` | `clue.schema.json` |
+| `[[types/Note]]` | `note.schema.json` |
+| `[[types/Session]]` | `session.schema.json` |
+| `[[types/Player]]` | `player.schema.json` |
+| `[[types/Transcript]]` | `transcript.schema.json` |
+| `[[Reference]]` | `reference.schema.json` |
+| `[[Type]]` | `type.schema.json` |
+| `[[Status]]` | `status.schema.json` |
+
+Schemas apply to typed records; unfinished templates are a separate category.
+References are local. The tests enable URI and date format assertions.
+
+## Limits
+
+Body regexes check basic structure. Duplicate headings and matching fenced text
+can satisfy Content/Session heading checks; Transcript checks only one heading
+and attributed entry. Clue requires Sessions plus one Base embed, but cannot establish that
+it executes or that the embedded Base exists. Content’s Active Clues and each
+Session preparation view section also require exactly one Base embed; other
+sections retain their free Markdown content. Link existence, target kinds, campaign and
+filename identity, chronology, reciprocal relationships and history consistency
+require vault-aware validation.
+
+## Tests
+
+From the repository root, without installing Armarium:
+
+```sh
+python3 -m venv /tmp/armarium-schema-venv
+/tmp/armarium-schema-venv/bin/pip install -r tests/schemas/requirements.txt
+/tmp/armarium-schema-venv/bin/python -m pytest tests/schemas -q
+```
+
+Tests cover meta-schemas, offline references, parsed JSON fixtures, committed
+Markdown records and identical schema/type-reference copies in both vaults.
+The PyYAML fixture loader is test support, not a production parser.