# Core Standards

Authoritative platform standards bundled with `@stravica-ai/engineering-pa-core`. Every operator instance inherits these; operators MAY extend (more-restrictive only) at `operator/knowledge/engineering/standards/`.

| File | Governs |
|---|---|
| [`tooling.md`](./tooling.md) | Shared and library tools under `packages/*/` and `operator/extensions/tools/`. Identity, structure, CLI, exit codes, testing, README-as-contract, audit records. |
| [`briefing-contract.md`](./briefing-contract.md) | The 8-section structured prompt every orchestrator-to-worker dispatch uses. |

## Why these live in the package

These standards are load-bearing for `roles/*/definition.md` and for every tool README under the package's `docs/tools/`. The package-versioned standards travel with the same release cycle as the code that depends on them, so a role definition that names a bolt-on can rely on it being present at the named path.

In v1 (the predecessor `Stravica/dave` fork-and-merge model) this same property was enforced by a lint at `core/tools/lint-core-isolation/`, which guarded against `core/` files referencing operator-owned paths. The package boundary now enforces the same structural rule: nothing inside `@stravica-ai/engineering-pa-core/` can reference an operator-only path, because the package install is read-only on every operator machine; the lint became redundant and was retired.

## Operator extensions

If your operator layer needs additional rules; operator-private CLI conventions, host-specific chokepoints, naming for operator-private runtime targets; add them at:

```
operator/knowledge/engineering/standards/<name>.md
```

The operator-side document MUST cite the core standard it extends and state only the operator-specific *additions*. It MUST NOT contradict any rule in the core standard.