> ## Documentation Index
> Fetch the complete documentation index at: https://slopsentral.michne.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Engineering practice

> Connect invariant design, executable evidence, and source-backed explanations.

Software Engineering owns the shared design and delivery practice.
Engineering Excellence is a retired plugin name. Use `software-engineering@slopsentral` for its current procedures.
The [migration map](https://slopsentral.michne.com/reference/migration.md) preserves the ownership change.

The practice connects an implementation, its executable evidence, and its source-backed explanation.
Each supports a different reader question. Keep their claims and evidence consistent throughout a change.

## Select The Plugin

Start with Software Engineering for invariant design, tests, Python automation, Git, PRs, and CI.
Add the language or platform specialty for the implementation in scope.
Use Repository Knowledge for substantial knowledge or documentation work.
The [catalog](https://slopsentral.michne.com/reference/catalog.md) owns current names and composition.

The [context hook](https://github.com/amichne/slopsentral/blob/main/source/hooks/software-engineering-context.hook.json) delivers the shared policies.
The host owns discovery and trust. A projected hook does not prove native consumption.
Task-selected skills keep their own procedures and references.

## Use The Standard

Before a substantial change, name the consumer, observable result, invariant, scope, and non-goals.
Start with the implementation that owns the requested behavior.
Trace one real path when behavior crosses components.
Choose reuse, extension, a new owner, or investigation from that evidence.

Use [Semantic Ratchet](https://github.com/amichne/slopsentral/blob/main/source/skills/semantic-ratchet/SKILL.md) when later consumers need facts that an earlier operation establishes.
Parse input once into constrained values or closed failures.
Make consumer contracts accept those values. Keep unchecked construction under the invariant owner.

Give sequencing, cancellation, state transitions, and completion one coordinator when they belong to one operation.
Keep domain decisions deterministic. Pass effect results through explicit adapters.
Preserve expected failure identities and unknown failures.
The [engineering baseline](https://slopsentral.michne.com/reference/engineering-standard.md) defines the shared rules.

## Keep the explanation with the software

Use the existing OKF owner for the system explanation.
In this repository, OpenWiki owns [source-linked concepts](https://slopsentral.michne.com/knowledge/quickstart.md) and their native Claims lifecycle.
A second wiki or copied explanation adds a competing owner.
Operational commands stay in their authored guides and link to the system concepts.

Explain the owner, entry point, flow, legal state, failures, and recovery that a reader needs.
Link material claims to source evidence and related concepts.
Prefer a specific interface or behavior over a directory inventory.
Distinguish current behavior, accepted decisions, proposals, and unresolved questions.

After a source change, examine the affected source links and freshness result.
Recheck the claim against current source before the page becomes current.
If the explanation remains accurate, record that review without an unnecessary prose change.
A resolving link or recent timestamp cannot establish factual freshness.
The [documentation practice](https://slopsentral.michne.com/maintainers/documentation.md) defines coverage, links, stale evidence, and completion.

An ordinary code change needs proportionate review of affected knowledge.
It does not authorize an unrelated documentation expansion, model evaluation, or publication.

## Inspect The Evidence

Use [TDD](https://github.com/amichne/slopsentral/blob/main/source/skills/tdd/SKILL.md) for a faithful executable oracle and its nearest negative case.
A behavior-change assertion must fail for the missing behavior before implementation.
Unavailable tools, invalid fixtures, timeouts, and empty selections do not establish that failure.
Start reuse and behavior-preserving refactors from passing characterization.

Compiler rejection supports encoded type constraints. Schema rejection supports external record constraints.
Runtime evidence supports effects, concurrency, persistence, and live host claims.
A static result cannot replace evidence from the mechanism in the claim.

Documentation gates establish structure, source linkage, and freshness within their declared scope.
The prose assessment measures its fixed policy and glossary.
Neither result proves comprehension or complete semantic accuracy.
Independent source review remains necessary.

Report the result, changed owners, exact outcomes, and material gaps.
Use **passed**, **failed**, **skipped**, or **not run** for each executed or omitted gate.
Keep historical model results separate from current local, CI, native, and live evidence.
The [eval guide](https://slopsentral.michne.com/maintainers/evaluations.md) defines those evidence limits.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.