modus-reinit

What does modus-reinit do?

Used for full review of existing content. Shares Evidence Guide, Authoring Framework, and Publication Contract; this document describes only the reinit differences.

First inventory, then prove changes

Fully read existing content and hashes, classifying targets as unchanged, anchor-only, implementation-change, scope-change, content-repair, suspected deprecation, or human-authored content. Stable identities and main definitions are reused by default; source path/symbol moves only modify anchors, content layout changes are not scope changes.

content-repair includes: generic template paragraphs replacing real scenarios, representative anchors replacing facts, cross-module copies, unclear completion/failure semantics, and complex relationships missing significantly helpful diagrams. Content that truly satisfies reader tasks and has unchanged facts remains unchanged and is skipped.

Execution

1. Build the current round of evidence once in a single repository and obtain the reinit-diff context; fail immediately and fall back to the current source. Expand directionally according to the Machine Evidence Packet, do not read bundle internal files directly, and do not exhaust the cursor.

2. Follow Scope Modeling in the order "stable identity → entry/object responsibility → semantic change → structural change → file change" to determine scope, handle, hash at read time, precise Domain/Module evidence/status, Domain coverage, outcome, and diagram candidates, writing them into a single schemaVersion: 2 execution card. Only confirm additions, splits, merges, moves, renames, or proven deprecations once. Default is serial execution; when the user explicitly authorizes and there are multiple non-overlapping affected Domains, load Parallel Domain Authoring and use the Domain Worker Prompt Contract; the root author continues exclusive control of the execution card and shared artifacts.

3. For each changed or content-repair Module, request the module-authoring context with a precise selector, verify double summaries and requestedScope; broad requests covering multiple independent Modules within the entire Domain are invalid. Precise requests that are independent can be concurrent, then aggregated and deduplicated for the current Domain's source paths/symbols, and read back in batches. If a request fails, returns empty, or is partial, fall back to the current method body, configuration, SQL, and tests for supplementation; do not treat class names, interface signatures, or file first-line anchors as content recovery. Do not repeatedly scan the same link for different topics, nor concurrently write the same content. Re-prove according to Scenario Closure; revise in the original main definition, do not append changelogs, and do not batch rewrite or redraw due to template changes.

4. In full Domain batches, read back the affected scope in the order "six-topic main definition → Module scenarios → Domain routing". Migrate source paths and line numbers to the small anchors.locations in each generated document's frontmatter; remove full source paths, path#L, and evidence lists from the body. The goal of repair is to restore complete tasks, field semantics, key branches, states, and error recovery, not to make files have titles, anchors, or similar lengths again. After evidence closure, re-evaluate candidates according to Visual Expression and update the single main diagram; navigation tables do not replace explanatory diagrams. Domain-level coverage-audit must reuse the candidate/capability/source path/symbol scope of this Domain, do not use modus/knowledge/**; no-match, empty results, or partial results only trigger supplementation or explicit gaps. Record valid results as Domain coverage. After completing three categories of reader readback, the root author reads the actual files and marks them as reviewed. Only update the root overview for cross-domain direction, ownership, status, conditions, completion, or recovery changes. Team Standard and existing business are protected by default bytes; for new Domains, use modus knowledge seed-business --domain <slug> --json to create missing indices.

5. For structural changes, first write the new destination and pass semantic readback, fix generated content inbound links and navigation, then delete old generated files based on read-time hashes. Do not infer deprecation directly from symbol disappearance, partial results, or coverage gaps.

6. After global semantic readback, run modus knowledge verify --publication --json, perform CAS publication and readback. Publication must verify schemaVersion: 2 execution card, no source paths in content, structured anchors, per-module evidence, Domain coverage, and visual decisions; clean is not yet evidence of content quality. Continue revision if there are many short texts of the same length, no real scenarios, only navigation tables, status topics without transitions, or evidence only on the first line of the file. Do not delete execution cards prematurely, and do not reconstruct a smaller "all reviewed" card from output after loss. Only clean up the execution card when all confirmed targets have reached the final state and semantic readback, actual publication, and post-publication readback have all passed; ordinary mechanical checks do not replace publication. Report accurately as unchanged, revised, deleted, conflicted, or gapped.