torben/chemenu

Fork 0

Files

T

torben f4353ccfb3

CI / verify (push) Successful in 52s

Details

Release / release (push) Successful in 35s

Details

raw accept: Datums-Shard statt Typverzeichnis, fidelity/authority am Drop-Punkt (Teil 1/3, #67 )

Files changed:
- .gitignore
- CHANGES.md
- VERSION
- instructions/bootstrap.md
- instructions/wiki-ingest/SKILL.md
- kb/CONTRACT.md
- raw/CONTRACT.md
- tools/CONTRACT.md
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/new_page.py
- tools/chemenu/commands/raw_cmd.py
- tools/chemenu/commands/touch.py
- tools/chemenu/lint_core.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_lint.py
- tools/chemenu/tests/test_new_page.py
- tools/chemenu/tests/test_provenance.py
- tools/chemenu/tests/test_raw_cmd.py
- tools/chemenu/tests/test_touch.py
- tools/chemenu/tests/test_type_resolver.py
- tools/chemenu/type_resolver.py
- types/source.md
- types/source.schema.yaml

2026-09-08 21:42:27 +02:00

4.2 KiB

Raw Blame History

type, name, description

type	name	description
types/instruction.md	bootstrap	Prepare a fresh clone for work - create the tools venv and publish the skills into the harness directories, which are generated and not committed.

Bootstrap a fresh clone

.agents/skills/ and .claude/skills/ are generated copies of the skill directories under instructions/, and both are gitignored. A fresh clone therefore has no skills at all until they are published: the agent harness will not offer wiki-ingest, wiki-query, wiki-manage, wiki-lint or wiki-status before this runs.

When to run

After cloning the repository.
After instructions/<name>/SKILL.md is added, renamed, or edited.
Whenever tools/wikitool instructions verify reports a missing or drifted copy.

Steps

Create the tool environment (once per clone):

cd tools
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
cd ..

Create the ingest inbox. incoming/ (raw/CONTRACT.md "Getting a file in") is gitignored, so a fresh clone does not have it at all - unlike raw/ itself, which is committed and present immediately. It is flat since Gitea #67 (no type subdirectory to create):
```
mkdir -p incoming
```
tools/wikitool doctor only reports a missing one; it never creates it, so this is a one-off catch-up here the same way step 5 below is for personalization.
Publish the skills:
```
tools/wikitool instructions sync
```
Verify:
```
tools/wikitool instructions verify
```
Expected: OK. If it reports drift, re-run sync - the source under instructions/ always wins, and a copy is never edited directly.
Check for personalization. A clone predating the personalization files has no USER.md/SOUL.md, and tools/wikitool doctor reports personalization: FAIL for it. That is a one-off catch-up, not a bootstrap step that repeats: run only the Personalization step (6) of setup-instance.md, not the whole procedure - this clone already has its git repo, author identity and content. A clone that already carries both files needs nothing here.
Offer to record the environment. ENVIRONMENT.md is gitignored, so a fresh clone never has one, and every session in it re-asks which harness is in use, which MCP servers are reachable, and which remote publish talks to. Copy ENVIRONMENT.md.template to ENVIRONMENT.md, fill in what is already known from this clone (git remote -v, the harness you are running in, tools/wikitool instructions list), ask the user for the rest, and drop the wikitool:template-unfilled line.

Optional, and it stays optional. Skip it and everything still works - doctor reports environment: absent (optional), not a failure. Skip it silently, though, and the next session pays for it again. Never guess an entry: a wrong remote or an MCP server that is not there is worse than the empty section it replaced, because it gets believed.
Restart the agent session if it was already running. Harnesses read the skill directories at startup, so skills published mid-session are not picked up.
Expect a lingering session-id WARN. A tools/wikitool doctor run at this point reports OK throughout except session-id: WARN - that check is scoped to the working session, not the clone, so a freshly bootstrapped checkout with no WIKITOOL_SESSION_ID exported yet always shows it. This is expected, not a Bootstrap gap: exporting it here would only be true for this one-off setup run, not for whichever session picks up the actual work next, in a new shell after step 7's restart. Run session-setup.md at the start of that session instead.

Scope

This does not apply to anything under kb/, raw/ or reports/; those are committed and present immediately after a clone. If the wiki content looks wrong after cloning, that is a lint question, not a bootstrap one.

This also does not apply to a fresh instance created via tools/wikitool dist export - it has no git history, no author identity, and no generated indexes yet. That is setup-instance.md, a longer procedure this one is a single step of.

4.2 KiB Raw Blame History

Bootstrap a fresh clone

When to run

Steps

Scope

4.2 KiB

Raw Blame History