git:20260715.3e93ae7 to git:20260719.88e075a

---

name: lingtai-kernel-dev

description: >

Mandatory repository-local development guide for LingTai's Python kernel and

runtime. Use this before changing code, architecture documents, tests,

packaging, capabilities, adapters, or developer documentation in

lingtai-kernel. Routes each task through the exact baseline, the distributed

ANATOMY/CONTRACT systems, focused validation, and pull-request safety gates.

related_files:

- ANATOMY.md

- CONTRACT.md

- CONTRIBUTING.md

- docs.yaml

- src/lingtai/intrinsic_skills/lingtai-kernel-anatomy/SKILL.md

- tests/test_architecture_documents.py

maintenance: |

Mandatory repository-local development router; update it, tests/test_architecture_documents.py's public-entry-points test, and README/Anatomy/Contract entry routes together whenever the workflow, the docs.yaml governance pointer, or the pull-request/side-effect gate changes.

---

# LingTai Kernel Development

Read this skill before every development task in this repository. It owns the

## First establish the task and baseline

1. Re-read the latest human or maintainer instruction. Separate the requested

change from suggested follow-up work and from unauthorized side effects.

2. Name the selected baseline: normally live `origin/main`, or an explicit tag

or commit chosen by the maintainer.

3. Work in a real repository worktree. Before analysis or editing, prove the

worktree is clean and `HEAD` equals the selected baseline. A directory name

or recorded SHA without equality is not enough.

4. Use a focused branch and keep unrelated local/runtime worktrees untouched.

See [`CONTRIBUTING.md`](../CONTRIBUTING.md) for the public contribution

workflow and its route to the full coding-agent and test reference.

## Read the distributed systems before editing

Use progressive disclosure in this order:

3. Read the cited code and narrow tests. Anatomy is navigation, not evidence in

place of code; Contract is the normative promise, not a description to weaken

when implementation drifts.

4. Load a narrower manual only when the task needs its commands, examples, or

troubleshooting. Do not preload unrelated references.

## Make the smallest complete change

Before editing, state the relevant invariant, the intended variation axis, and

the explicit non-goals. Prefer one behavior-locked boundary or vertical slice

over a directory reshuffle or speculative abstraction.

For every code or architecture-document change, assess both distributed systems:

- Files, symbols, connections, composition, or state ownership changed:

update the relevant Anatomy in the same PR.

- Port, Adapter, Behavior, error, ordering, retry, cancellation, recovery, or

state semantics changed: update the relevant Contract and shared contract

tests in the same PR.

- Both changed: update the pair together.

- Neither changed: record that both were checked; do not create documentation

churn to simulate compliance.

### Classify the Anatomy/Contract relationship first

### Keep Maintenance guidance aligned

When you create or update a child component `CONTRACT.md`, keep its

`maintenance` note concise and aligned with root [`CONTRACT.md`](../CONTRACT.md):

retain complete, safe `related_files`, reciprocal Anatomy/Contract and ownership

links, and the rule to update the pair when structure or normative behavior

changes. The note is documentation, not a byte-identical snapshot; do not add a

second registry or a generated/hash-based maintenance mechanism.

## Validate in layers

Run the narrowest decisive checks first, then the affected broader checks. At a

minimum:

```bash

python -m pytest -q <targeted-tests>

python -m pytest -q tests/test_architecture_documents.py # when either graph changes

# Run the canonical Anatomy drift checker in --check mode (see the Anatomy skill).

git diff --check

```

Also run package, import, build, adapter, or source-drift tests when the diff

crosses those boundaries. Use the repository virtual environment, inspect every

non-zero exit, and never report a timed-out or interrupted suite as passing.

Review the final diff against the human instruction and name any untested risk.

## Pull-request and side-effect gate

Use a pull request; never push directly to `main`. Before committing, pushing,

or opening the PR:

1. re-read the latest human scope and authorization;

2. verify live base equality and stop if the base moved;

3. verify local Git author identity and the intended GitHub CLI account;

4. ensure the staged diff contains only the reviewed change;

5. capture focused validation evidence and unresolved risks.

Commit, push, open/close/merge PRs, publish, install, refresh, release, or change

configuration only within the maintainer's explicit authorization for that

specific side effect. Opening a PR does not imply permission to merge it.

## Keep documentation frontmatter current

Every Markdown file in the repository — including this file's own

frontmatter above — must carry `related_files` and `maintenance` YAML

metadata, checked by [`docs.yaml`](../docs.yaml) and validated by

`scripts/check_docs_governance.py` / `tests/test_docs_governance.py`. This

is a separate, generic baseline from the Anatomy/Contract frontmatter

schemas above — do not conflate them. When you add or edit a doc, fill in

real `related_files`/`maintenance`; when you create a new governed

component ANATOMY.md/CONTRACT.md, its stricter specialized schema already

satisfies this baseline.

## Grow this as the repository agent dev kit

This directory owns the kernel repository's complete reusable development kit,

not only this entry document. Add supporting material when real repeated work