# Changelog All notable changes to the Intransic skill are recorded here. The version in `.claude-plugin/marketplace.json` and `intransic-skills/.claude-plugin/plugin.json` must match the most recent released entry below. A release is a git tag of the form `v`. ## [0.2.2] — 2026-09-18 ### Added - **`infra_posture` conformance kind.** Reads a committed infrastructure snapshot and flags any posture the Foundation's `boundaries` or `security` sections never mention — a database reachable over the public internet, a firewall rule admitting a whole cloud, TLS below 1.2, an application authenticating as a server admin. Every other rule works by falsifying a claim, which leaves undeclared posture structurally invisible: a Foundation cannot contradict a claim nobody made. Declaring a posture satisfies the rule even if the declaration accepts it — accounting for it is the bar. Reads a snapshot rather than shelling out to a cloud CLI, so validation stays reproducible and cloud-agnostic. Documented in `validation/README.md`, with a worked four-posture example in `templates/validation-rules.yaml`. ## [0.2.1] — 2026-08-09 ### Changed - **Ownership.** The skill is owned by **Intransic Data Pty Ltd** (`intransic.com`), not by Ascenda One. Licence copyright, plugin author, marketplace owner, homepage and repository URLs updated. The repository moves from `ascendaone-com/intransic-skill` to `intransic/intransic-skill`. Ascenda's role is design partner and first customer — not proprietor. - **The origin story is de-identified.** It previously named the subject repository and described the dropped enforcement attribute by attribute. That is a disclosure about a running production service, not an illustration: it published the system, the vulnerability class, and — since no test asserts the property yet — confirmation that the gap remains open. The mechanism, the timing and the lesson are unchanged; the target is gone. `README.md` and `reference/process.md`. ## [0.2.0] — 2026-08-09 Two inconsistencies in 0.1.0, both cases where the skill stated a discipline it did not enforce. ### Added - **Evidence strength ladder** — `existence` · `implementation` · `behavioural` · `operational` · `deployed` · `independent`, with a per-type default and an optional `strength:` field on each evidence item. Recorded in `SKILL.md`, `validation-rules.yaml` and `validation/README.md`. - **`E-11`** — `verified` requires at least one evidence item of `behavioural` strength or better. 0.1.0 required only that *some* evidence existed (`E-03`), so a single citation of a file that merely exists satisfied it. The claim in the origin story could have been marked `verified` on exactly that basis: the rate-limit attributes were in source, and nothing executed asserted them. Below `behavioural`, the supportable status is `implemented_unverified`, which the vocabulary already provided. - **`E-12`** — no publishable status may rest entirely on `documentation` or `git` evidence. `SKILL.md` said "documentation is a claim to be verified, never evidence"; nothing stopped a ledger entry being supported by documentation alone. - Both rules also as conditional subschemas in `evidence.schema.json`, so a ledger fails on the same grounds where the validators are ported. ### Changed - **Foundation authority split into two questions.** 0.1.0 said the Foundation "outranks every other document in the repository" *and* that implementation outranks documentation — which conflict, and would let a stale Foundation overrule working code. Now: implementation and executed tests are authoritative on **what is currently true**; the Foundation is authoritative on **what must remain true** (`change_constraints`, domain invariants). Where they disagree, that is a contradiction to record and resolve deliberately, never a silent win for either side. `README.md`, `SKILL.md`, `reference/process.md`. - `validate_evidence.py` covers `E-01..E-12`; `_common.py` gains the strength model (`EVIDENCE_STRENGTHS`, `DEFAULT_STRENGTH_BY_TYPE`, `evidence_strength`, `meets_strength`). - `prompts/trust-wall-refresh.md` and `prompts/release-validation.md` state the strength requirement at the points where a status is upgraded. - `validation/README.md` records what `E-11` cannot establish: it reads the ledger, so it checks that behavioural evidence was *cited*, not that the test *passed*. ## [0.1.0] — 2026-08-09 First packaged release. Extracted from a run of the process against a production .NET backend in July 2026. ### Added - `skills/intransic/SKILL.md` — entry point, authority order, status vocabulary, operating rules, execution sequence. - `skills/intransic/reference/process.md` — the full ten-phase process. - `skills/intransic/prompts/` — change review, release validation, trust wall refresh, repository review. - `skills/intransic/templates/` — `intransic.config.yaml`, claim policy, publication policy, validation rules. - `skills/intransic/schemas/` — foundation, evidence and trust-claim JSON schemas. - `skills/intransic/validation/` — `validate_foundation.py`, `validate_evidence.py`, `validate_trust_wall.py` and shared helpers. - Claude Code plugin packaging: marketplace and plugin manifests. ### Changed - Distribution moved from a manual `cp -R` into `~/.claude/skills/` to installation through the Claude Code plugin marketplace. The skill now lives at `intransic-skills/skills/intransic/` rather than `intransic-skills/intransic/`.