v0.14.0

Added

• azure-devops-wiki and a new azure-devops target build links. kac export addressed github alone. A corpus
  publishing to an Azure DevOps wiki now gets a ?pagePath= link per record, and one publishing to Azure Repos without
  a wiki gets a ?path=&version=GC<sha> link. kac new --publishing azure-devops accepts the new target and fills its
  base in from a dev.azure.com remote, in either the SSH or the HTTPS spelling. A wiki base has to be typed in,
  because a repository's remote says nothing about which wiki publishes it.

  A wiki link is not pinned to a commit, because no ?pagePath= URL takes one. An agent still reads the version the
  export was built from. docs/corpus-descriptor.md sets out both targets.

  The azure-devops link form and the anchor an Azure DevOps wiki resolves for a heading carrying punctuation are both
  unconfirmed against a live organisation. The wiki's page path, its anchor parameter and its rejection of a base
  carrying a page id are confirmed.

• kac pack seals an export into a versioned package. It reads .dist/export/ and writes one file to
  .dist/package/, named for the corpus and its content-version. The file is a .nupkg, which is a zip carrying a
  small XML manifest a registry reads to name and version it, and both GitHub Packages and Azure DevOps Artifacts
  store one. Everything under corpus/ inside it is the export, byte for byte, so nothing reading the result needs a
  NuGet client. Two runs over one export produce identical bytes.

  The command refuses a corpus that has not declared corpus:, content-version: and shortcode: in .corpus.yaml,
  naming the one that is missing. It publishes nothing: pushing the file is your pipeline's step, and docs/cli/pack.md
  carries the command for it.

• kac pack --repository <URL> names where the corpus's source lives. Some registries read that URL to decide
  which repository a package belongs to, and GitHub Packages refuses a package naming none when the token pushing it
  is scoped to a repository. The element is left out where the flag is not given, because the export states where a
  record is published and that is a different address.

• A policy-lookup skill travels in the plugin. kac bundle ships it beside glossary-lookup, and a corpus
  carrying no policies has it trimmed. It reads policies/clauses.jsonl, answers from a clause's level rather than
  from the modal in its wording, and says which of the four levels it found. What an external framework obliges stayed
  behind with the register that explains it, so the skill names that gap rather than filling it.

• A component says whether the breadcrumb names it. "announce": true on a manifest entry puts that skill in the
  breadcrumb's last line, and the default leaves it out. The line exists to create a question a session would not
  think to put, so a skill somebody asks for by name does not earn it. A corpus adding a second skill sets announce
  on the one worth introducing.

• plugin.from in .corpus.yaml reads the plugin tree from one shared folder. Several corpora in a repository
  keep one copy of the skills and hooks between them instead of a copy each. kac bundle merges that tree with the
  corpus's own .plugin/, where a file the corpus holds wins, and kac update withholds the shared half rather than
  writing it back. The manifest is never taken from the shared tree: it names the plugin, so it stays at
  .plugin/.claude-plugin/plugin.json in each corpus. Omit the key and nothing changes. A corpus adopting the key
  with the old copies still on disk has each one reported as a file the template sends nothing to, because a corpus's
  own file wins the merge and a leftover would go on shipping after every upstream change.

• A corpus created before this declares no component for the new skill. kac update writes the skill, and leaves
  .plugin/.claude-plugin/plugin.json alone because the manifest is the corpus's own. A path no component owns ships
  unconditionally, so add the component yourself to have it trimmed where the type is not adopted:

  {
    "path": "skills/policy-lookup",
    "requires": [ "policies@2" ],
    "note": "Reads a clause from corpus/policies/clauses.jsonl and the owning policy beside it."
  }