@memorax/memorax-code 0.1.2 → 0.1.4

package/lib/memorax-code-claude-marketplace/plugins/memorax-code-claude-adapter/skills/memorax-code/references/personal-read.md

@@ -39,7 +39,7 @@ python3 <skill-dir>/scripts/user_profile_memory.py list --repo <repo>
 
 Use only active preferences returned by the script. If the preferences file does not exist, report that no user-profile memory is available; the list operation does not create it.
 
-Mention only preferences relevant to the current request unless the user explicitly asks to list all of them. Stored preferences describe how Codex should interact with the user; they are not repository facts.
+Mention only preferences relevant to the current request unless the user explicitly asks to list all of them. Stored preferences describe how the coding agent should interact with the user; they are not repository facts.
 
 ## Priority
 

package/lib/memorax-code-claude-marketplace/plugins/memorax-code-claude-adapter/skills/memorax-code/references/personal-write.md

@@ -21,27 +21,36 @@ Before writing, ensure the repository root `.gitignore` contains `.repo_memory/`
 
 Do not create a global procedures file, index, event log, generated metadata, or version history. Do not edit `.repo_memory/PROFILE.md`, `.repo_memory/resources/`, `.repo_memory/raw/`, or `.repo_memory/user-profile/`.
 
-Choose the closest existing topic file. Update it when the user refines the same procedure; create a new file only for a distinct topic. Remove superseded wording rather than preserving old versions.
+Choose the closest existing topic file before writing:
+
+- New topic: create a file.
+- Addition or refinement to the same topic: update the existing file.
+- A new rule directly conflicts with or replaces an old rule: update the existing file and remove the superseded content.
+- An old rule references a command, file, or workflow that no longer exists: update the invalid part; delete the file if the entire procedure is obsolete.
+- Equivalent content: do not add a duplicate.
+- If it is unclear whether the change is durable or only applies to the current task: ask the user.
+
+Do not modify existing memory because of a one-time instruction for the current task. Do not scan or clean up unrelated topics.
 
 Use this shape when useful:
 
 ```markdown
-# 代码审查
+# Reviewing Code
 
-Use when: 审查当前仓库中的代码变更时。
+Use when: reviewing changes in this repository.
 
 ## Procedure
 
-1. 创建 PR 前先审查变更。
-2. 解决阻塞性问题。
-3. 审查完成后再创建 PR。
+1. Review the changes before creating a PR.
+2. Resolve blocking findings.
+3. Create the PR only after review is complete.
 
 ## Exceptions
 
-- 优先遵循用户当前提出的更具体指令。
+- Follow a more specific current user instruction first.
 ```
 
-Delete only the topic file or section the user explicitly identifies. Do not retain deleted text in tombstones, backups, inactive entries, or history files.
+Delete only the topic file, section, or step the user explicitly identifies, and preserve unrelated content. Do not retain deleted text in tombstones, backups, inactive entries, or history files. Apply the same rule to superseded text.
 
 ## User-Profile Memory
 
@@ -59,15 +68,26 @@ List existing preferences before adding and perform semantic matching:
 python3 <skill-dir>/scripts/user_profile_memory.py list --repo <repo>
 ```
 
-If equivalent content exists, do not add it again. Update the matching id when an existing entry expresses the same preference differently. Add only a genuinely new preference:
+Handle the semantic match before writing:
+
+- New preference: add a new preference.
+- Equivalent content: do not add a duplicate.
+- Addition or refinement to the same preference: update the existing preference.
+- A new preference directly conflicts with or replaces an old preference in the same scope: update the existing id and remove the superseded content.
+- The user explicitly says a preference no longer applies: delete that preference.
+- Its `Applies when` environment, tool, or workflow no longer exists: update the scope; delete it if the entire preference is obsolete.
+
+Do not modify or delete existing preferences because of a one-time instruction for the current task. Do not scan or clean up unrelated preferences.
+
+Use the matching id for updates. Add only a genuinely new preference:
 
 ```bash
 python3 <skill-dir>/scripts/user_profile_memory.py add \
   --repo <repo> \
   --type communication \
-  --description "用户希望在当前仓库中使用简洁的中文回答。" \
-  --applies-when "回答当前仓库相关问题时。" \
-  --do-not-apply-when "用户明确要求使用其他语言或格式。"
+  --description "User prefers concise Chinese answers for this repository." \
+  --applies-when "Answering questions in this repository." \
+  --do-not-apply-when "The user explicitly requests another language or format."
 ```
 
 Allowed script types are `communication`, `workflow`, `environment`, and `profile`. These type names do not expand this authority: never use `workflow` or `environment` to store an executable repository procedure.
@@ -83,7 +103,7 @@ python3 <skill-dir>/scripts/user_profile_memory.py update \
   --do-not-apply-when <exception>
 ```
 
-If multiple preferences may match, ask the user to choose before updating. Delete only an explicitly identified preference:
+If multiple preferences may match, or it is unclear whether the change is durable, ask the user. Delete only an explicitly identified preference:
 
 ```bash
 python3 <skill-dir>/scripts/user_profile_memory.py delete \

package/lib/memorax-code-claude-marketplace/plugins/memorax-code-claude-adapter/skills/memorax-code/references/repo-build.md

@@ -15,6 +15,7 @@ The user selects a repository, not a memory directory. Do not ask for a `.repo_m
 ```text
 <repo>/.repo_memory/
 ├── PROFILE.md
+├── <repo-native-topic>.md conceptual pages
 ├── raw/
 │   ├── prepare-report.json
 │   ├── git-commits.json
@@ -25,10 +26,35 @@ The user selects a repository, not a memory directory. Do not ask for a `.repo_m
     └── issues.md
 ```
 
-Script-generated artifacts: `raw/prepare-report.json`, `raw/git-commits.json`, and optional `raw/github-facets.json` or `raw/gitlab-facets.json`. Agent-authored durable artifacts: `PROFILE.md`, `resources/commits.md`, `resources/prs.md`, and `resources/issues.md`.
+Script-generated artifacts: `raw/prepare-report.json`, `raw/git-commits.json`, and optional `raw/github-facets.json` or `raw/gitlab-facets.json`. Agent-authored durable artifacts: `PROFILE.md`, repository-native supporting conceptual pages when the repository has enough surface area, `resources/commits.md`, `resources/prs.md`, and `resources/issues.md`. Temporary planning artifact `.repo_memory/_plan.md` is allowed during drafting but must be removed before final validation.
 
 User-managed sidecars may coexist under `.repo_memory/procedure-memory/` and `.repo_memory/user-profile/`. Builder scripts preserve them and exclude them from bundle validation; this skill must not create, edit, or summarize their contents as repo-memory evidence.
 
+## Wiki-Style Output Contract
+
+MemoraX repo memory is a wiki-style repository memory backed by raw mechanical evidence. The primary user-facing product is a readable wiki, not a dense schema dump or a history table.
+
+- `PROFILE.md` is the only fixed conceptual wiki file and the wiki landing page: project identity, what the repo contains, how it works, first-use path, Major Areas, Supporting Pages, provider context, and evidence inspected.
+- Do not assume fixed supporting page names. Decide supporting pages and filenames from the repository itself after discovery.
+- For very small repositories, `PROFILE.md` plus 1-2 supporting pages is enough. For most repositories, generate 3-7 Markdown pages total, including `PROFILE.md`. Only exceed 7 pages when the repository clearly has multiple substantial, independent areas that would become confusing if merged.
+- Every durable supporting conceptual page must include frontmatter with `schema: "repo_memory_wiki_page.v0.1"` so validation can scan it.
+- Supporting pages explain concepts, workflows, system areas, change surfaces, setup, verification, and agent routing cautions. They must link claims to inspected docs/source and use conservative wording when lightweight mode did not inspect source.
+- resources/*.md remain compact historical routing cards for commits, PRs/MRs, and issues. They should not be the main architecture explanation.
+- Keep raw JSON as debug evidence only. Do not ask future agents to read raw facets unless compact pages and resources are insufficient.
+
+## Conceptual Page Planning
+
+After discovery and before final wiki writing, create a temporary planning artifact at `.repo_memory/_plan.md`. Keep it compact. Use it to outline intended final pages, each page purpose, source evidence, page boundaries, canonical homes for overlapping concepts, remaining questions, weak evidence, and paths that must be verified before final writing.
+
+- Remove `.repo_memory/_plan.md` before final validation; it is not part of the durable repo memory bundle.
+- Organize pages like human documentation, not a raw file inventory. Use human documentation titles. Do not title pages or headings after source paths, and do not mirror the source tree.
+- Create a page only when a future human or agent needs a canonical explanation for a concept, workflow, system area, or change surface. A page is a durable orientation artifact, not a parking place for exploration facts.
+- Merge rather than split when two pages would repeat the same workflow, types, or source paths; when one page would only explain a subset of another page; or when the distinction is based on source directory layout rather than reader task or concept.
+- Split rather than merge when one page would mix unrelated reader tasks; when a concept has its own workflow, data model, risks, and source-backed change guidance; or when a page would become too long to navigate.
+- Prefer headings inside broader pages before creating many small pages. Avoid thin pages and stub-like pages.
+
+Natural documentation domains are candidates, not a required checklist: architecture, workflows, data model, integrations, operations, testing/evaluation, and extension points. In `_plan.md`, decide which candidates were selected, merged, or skipped and why. Generic names such as `architecture.md`, `runtime-flow.md`, and `developer-workflow.md` are fallback names only when repository vocabulary gives no stronger topic.
+
 ## Repository Prerequisite
 
 The selected target must be a local git repository: either the directory contains `.git/` or is inside a git worktree. A GitHub/GitLab remote is optional; local-only git repositories are supported.
@@ -60,19 +86,38 @@ Default mechanical collection settings are intentionally visible in `<skill-dir>
 
 ```json
 {
-  "schema": "repo_memory_builder_defaults.v1",
-  "limits": {
-    "commits": 30,
-    "prs": 30,
-    "issues": 30
+  "schema": "repo_memory_builder_defaults.v2",
+  "repoHistory": {
+    "mode": "provider",
+    "limits": {
+      "commits": 30,
+      "prs": 30,
+      "issues": 30
+    }
   },
   "summaryChars": 4000
 }
 ```
 
-To change defaults for future builder runs, edit `defaults.json`, not the Python scripts. To override one run, pass `--commit-limit`, `--pr-limit`, `--issue-limit`, or `--summary-chars` to `collect_all.py`.
+To change defaults for future builder runs, edit `defaults.json`, not the Python scripts. To override one run, pass `--history-mode`, `--commit-limit`, `--pr-limit`, `--issue-limit`, or `--summary-chars` to `collect_all.py`.
+
+Provider collection is best-effort by default. Use `--history-mode local-only` or `--skip-provider` for an explicit local-only run that does not call GitHub/GitLab, and use `--history-mode provider-required` or `--require-provider` only when the user explicitly requires PR/MR/issue evidence and the run should fail instead of falling back to local-only memory.
+
+## Historical Evidence Policy
+
+Historical evidence collection is configurable per run with `--history-mode` and by default with `repoHistory.mode` in `defaults.json`:
+
+| Mode | Commits | PRs/MRs and issues | Resource file contract |
+|------|---------|--------------------|------------------------|
+| `--history-mode none` | Disabled | Disabled | Write disabled resource files for commits, PRs/MRs, and issues using `source: "history_disabled"`, `resource_count: 0`, and `raw_source: ""`. |
+| `--history-mode commits-only` | Collected locally | Disabled | Write commit resources from `raw/git-commits.json`; write PR/issue files using `source: "provider_skipped_local_only"`, `resource_count: 0`, and `raw_source: ""`. |
+| `--history-mode local-only` | Collected locally | Disabled | Same as commits-only; use when the user wants local Git history but no provider calls. |
+| `--history-mode provider` | Collected locally | Best-effort | Default. Collect provider facets when ready; if provider evidence is unavailable or fails, continue local-only and mark PR/issue resources unavailable. |
+| `--history-mode provider-required` | Collected locally | Required | Fail the collection if provider facets cannot be collected. Use only when the user explicitly requires PR/MR/issue evidence. |
+
+`--skip-provider` is a compatibility alias for `--history-mode local-only`; `--require-provider` is a compatibility alias for `--history-mode provider-required`.
 
-Provider collection is best-effort by default. Use `--skip-provider` for an explicit local-only run that does not call GitHub/GitLab, and use `--require-provider` only when the user explicitly requires PR/MR/issue evidence and the run should fail instead of falling back to local-only memory.
+When history or provider evidence is disabled, skipped, unavailable, or degraded, still create `resources/commits.md`, `resources/prs.md`, and `resources/issues.md`; write disabled resource files for any historical channel that was not collected. The disabled or unavailable resource files tell future agents that the builder intentionally did not collect that evidence. For PR/issue files, do not say that no PRs or issues exist unless provider evidence was actually collected and empty.
 
 ## User Count Requests
 
@@ -150,7 +195,7 @@ Do not use a restricted shell sandbox to verify provider/API availability. Verif
 
 ### `scripts/validate_memory.py`
 
-Use this as the final gate after authoring `PROFILE.md` and `resources/*.md`. It accepts either the repository root or the memory root, validates required files, JSON parseability, frontmatter counts, placeholder removal, and provider raw/resource consistency.
+Use this as the final gate after authoring `PROFILE.md`, supporting conceptual pages, and `resources/*.md`. It accepts either the repository root or the memory root, validates required files, JSON parseability, frontmatter counts, placeholder removal, and provider raw/resource consistency.
 
 ```bash
 python3 <skill-dir>/scripts/validate_memory.py <repo-path> --pretty
@@ -200,9 +245,12 @@ Run: `<notice.command>`
    - Form project-level understanding before looking at PR/issue history.
    - Record whether conclusions are doc-derived or code-inspected.
 
-4. **Draft `PROFILE.md`**
+4. **Plan and draft the wiki landing page and conceptual pages**
    - Read [repo-templates.md](repo-templates.md) before writing memory files.
-   - Include repo identity, checkout state, evidence inspected, agent consumption rules, module map, verification gates, architecture boundaries, resource pointers, and retrieval flow.
+   - Create `.repo_memory/_plan.md` after discovery and before final wiki writing. Use it to cluster repository-native conceptual areas, page purposes, evidence, boundaries, canonical homes, merge/split decisions, weak evidence, and path verification needs.
+   - Write `PROFILE.md` as the wiki landing page with repo identity, checkout state, what the repo contains, how it works, first-use path, Major Areas, Supporting Pages, provider context, and evidence inspected.
+   - Create repository-native supporting conceptual pages from the plan. Cover only concepts, workflows, system areas, or change surfaces with enough evidence to deserve canonical pages.
+   - Remove `.repo_memory/_plan.md` before final validation.
    - Record the selected build mode and avoid overstating code-level claims in lightweight mode.
 
 5. **Review raw evidence**
@@ -243,8 +291,9 @@ Every description must say what the item explains, when a future agent should op
 
 Generate memory that the `memorax-code` repo-read operation can consume progressively:
 
-- `PROFILE.md` is the stable entry point and should summarize identity, evidence, architecture, verification gates, and resource pointers.
-- `resources/*.md` are compact human-readable routing resources with search-grade descriptions.
+- `PROFILE.md` is the stable wiki landing page and should summarize identity, evidence, major areas, supporting pages, verification gates, and resource pointers.
+- Supporting conceptual pages are repository-native canonical homes for concepts, workflows, system areas, and change surfaces selected through temporary planning.
+- `resources/*.md` are compact historical routing cards with search-grade descriptions.
 - `raw/*.json` contains optional build/debug evidence for deep inspection when compact resources are insufficient.
 
 Do not duplicate the daily retrieval workflow here. The `repo-read` operation owns trigger timing, silent background-maintenance handoff, and task-specific search behavior.

package/lib/memorax-code-claude-marketplace/plugins/memorax-code-claude-adapter/skills/memorax-code/references/repo-read.md

@@ -2,7 +2,7 @@
 
 ## Role And Demand Gate
 
-Use existing `.repo_memory/` as a routing layer for repository identity, architecture, history, PR/issue context, remembered fixes, and cross-module search. Live code and tests remain authoritative.
+Use existing `.repo_memory/` as wiki-style repo memory for repository identity, architecture, history, PR/issue context, remembered fixes, and cross-module search. Live code and tests remain authoritative.
 
 Select this reference for broad repo introduction, history, architecture background, cross-module routing, PR/issue context, design rationale, or stale-memory awareness. Skip this reference for narrow tasks with a clear live-code target.
 
@@ -36,21 +36,27 @@ The default policy remains `adaptive(5 commits OR 24 hours)`. A missing or non-a
 
 ## Retrieval
 
-If `.repo_memory/PROFILE.md` is a readable regular file, read it once. Treat its descriptions as routing cues, not proof.
+If `.repo_memory/PROFILE.md` is a readable regular file, read `PROFILE.md` as the wiki landing page once. Treat its descriptions as routing cues, not proof.
 
-Search `PROFILE.md` and `.repo_memory/resources/` with a combined query built from the user's strongest handles: path, basename, symbol, command, PR/issue number, error text, module, branch, environment variable, or config key.
+Extract task-relevant links from `Major Areas` and `Supporting Pages`. Do not assume fixed page names; use `PROFILE.md` links and headings to find the repository-native canonical homes for the user's task. Open at most 2-4 relevant conceptual pages from `.repo_memory/*.md` before searching historical resources.
+
+Search `PROFILE.md`, `.repo_memory/*.md`, and `.repo_memory/resources/` with a combined query built from the user's strongest handles: path, basename, symbol, command, PR/issue number, error text, module, branch, environment variable, or config key.
 
 ```bash
 rg -n '<handle-1>|<handle-2>' \
-  .repo_memory/PROFILE.md .repo_memory/resources
+  .repo_memory/PROFILE.md .repo_memory/*.md .repo_memory/resources
 ```
 
 Use:
 
+- conceptual `.repo_memory/*.md` pages for repository-native canonical homes, workflows, system areas, change surfaces, and verification routing;
+- resources/*.md for historical routing cards;
 - `resources/commits.md` for local history and regressions;
 - `resources/prs.md` for merged or active implementation context;
 - `resources/issues.md` for symptoms, requests, and requirements.
 
+Disabled and unavailable historical resource files are collection state, not repository state. If a resource frontmatter uses `source: "history_disabled"`, `source: "provider_skipped_local_only"`, or `source: "provider_unavailable"` with `resource_count: 0`, do not conclude that there are no commits, PRs, MRs, or issues. Treat the channel as intentionally uncollected or unavailable; answer from available memory only. Ask whether to rebuild with provider history when that context matters.
+
 If a read is missing, unreadable, or structurally mixed, discard conclusions that depend only on the bundle. Do not repair it in the foreground.
 
 ## Retrieval Budget
@@ -58,6 +64,7 @@ If a read is missing, unreadable, or structurally mixed, discard conclusions tha
 - Read `PROFILE.md` at most once.
 - Run at most 2 combined `rg` commands.
 - Stop repo-memory retrieval as soon as the hits are sufficient.
+- Open at most 2-4 relevant conceptual pages total during the bounded memory phase.
 - Open only the matched resource section when `rg` context is insufficient.
 
 Do NOT open these unless the user explicitly asks or a compact hit contains only a `facetId`:

package/lib/memorax-code-claude-marketplace/plugins/memorax-code-claude-adapter/skills/memorax-code/references/repo-templates.md

@@ -4,11 +4,13 @@ Use these templates as fill-in scaffolds. Replace all bracketed placeholders wit
 
 ### `.repo_memory/PROFILE.md`
 
+`PROFILE.md` is the only fixed conceptual wiki file. It is a wiki landing page, not a dense resource index. It should read like a wiki-style repository memory home page: concise project identity, first-use path, major areas, supporting pages, and historical/provider pointers. Keep MemoraX frontmatter so the validator and maintenance hooks can still trust the bundle.
+
 ```markdown
 ---
-schema: "repo_memory_profile.v0.1"
-layout: "profile_with_progressive_resources.v0.1"
-disclosure_model: "progressive"
+schema: "repo_memory_profile.v0.2"
+layout: "wiki_landing_page.v0.1"
+disclosure_model: "progressive_wiki"
 repo_name: "[repo name]"
 repo_owner: "[owner or empty]"
 repo_full_name: "[owner/name or empty]"
@@ -32,91 +34,146 @@ raw:
   provider_facets: "raw/github-facets.json|raw/gitlab-facets.json|"
 ---
 
-# [Repo Name] Repo Memory Profile
+# [Repo Name] Repository Wiki
+
+[One short paragraph explaining what this repository is, who uses it, and the primary runtime/package/product surface. Ground this in inspected docs or source.]
+
+- Repository: `[owner/name or local repo]`
+- Local HEAD when prepared: `[sha]` on `[branch]`
+- Build mode: `[lightweight|deep]`; working tree was `[clean/dirty + explanation]`
+- License: `[license if known]`
+
+## What This Repo Contains
+
+| Area | What it does |
+|------|--------------|
+| `[repo-native product/module/workflow name]` (`path/`) | [Plain-language responsibility and primary entrypoint.] |
+| `[repo-native product/module/workflow name]` (`path/`) | [Plain-language responsibility and primary entrypoint.] |
+
+## How It Works
+
+[Five to ten sentences describing the main runtime/build/request/data flow. Link to supporting pages instead of explaining every detail here. Use conservative wording when lightweight mode did not inspect representative source.]
+
+## First-Use Path
+
+```bash
+[install or setup command]
+[one fast verification or smoke command]
+```
+
+[Explain the shortest safe path a future agent should use to orient, build, test, or run the project.]
+
+## Major Areas
+
+Choose these rows from `.repo_memory/_plan.md` after clustering inspected docs/source paths. Do not assume fixed page names; generic names are fallback names only when repository vocabulary gives no stronger topic.
+
+| Area | Page | What It Covers |
+|------|------|----------------|
+| `[repo-native area name]` | [`[human page title]`](./repo-native-topic.md) | [What task cluster this page routes and why it is a canonical home.] |
+| `[repo-native area name]` | [`[human page title]`](./repo-native-topic.md) | [What task cluster this page routes and why it is a canonical home.] |
+
+## Supporting Pages
 
-## Identity And Checkout
+- [`[human page title]`](./repo-native-topic.md) - open when [task cue, change surface, workflow, or risk].
+- [`[human page title]`](./another-repo-native-topic.md) - open when [task cue, change surface, workflow, or risk].
+
+## Agent Consumption Rules
+
+1. Read this file first, then open only the supporting page relevant to the task. Memory is a map, not proof.
+2. Verify current behavior against live source, configs, tests, or executable checks before editing or making strong claims.
+3. Treat commits, PRs/MRs, and issues as historical routing context; they do not prove current checkout behavior.
+4. Prefer source paths and commands linked from supporting pages over broad repository scanning.
+
+## Coding Memory Boundary
 
-- Repository: `[owner/name]` at `[absolute path]`.
-- Local HEAD when prepared: `[sha]` on `[branch]`.
-- Prepared at: `[timestamp]`; working tree was `[clean/dirty + explanation]`.
-- License: `[license if known]`.
-- Primary purpose: [1-3 sentences explaining what this project does, based on docs and code].
+This repo memory is a cold-start repository map presented as a repository wiki. Use it for module routing, architecture boundaries, verification gates, historical PR/issue context, and repository-specific conventions.
+
+Runtime coding memory is narrower and should take precedence when it matches the current repo, module, API, behavior, lifecycle surface, ownership boundary, or failure mode. Use runtime coding memory for verified repair invariants, failed-attempt evidence, mutable-state ownership, callback/hook boundaries, adapter behavior, validation contracts, and other task-learned engineering lessons.
+
+Do not treat repo memory, commits, PRs, or issues as implementation recipes. They are routing evidence and historical context. Always verify current behavior against live source and focused checks before editing.
+
+## Provider Context
+
+- [Historical commits](./resources/commits.md) - local checkout history and regression routing.
+- [Historical PRs/MRs](./resources/prs.md) - implementation context from provider facets when available.
+- [Historical issues](./resources/issues.md) - user/request/problem context when available.
+- Raw local commit facets: `./raw/git-commits.json`.
+- Raw code-host facets: `./raw/github-facets.json` or `./raw/gitlab-facets.json` when present.
 
 ## Evidence Inspected
 
-- Build mode: `[lightweight|deep]`.
 - Root docs and agent instructions: `[README/docs/AGENTS.md/CLAUDE.md or similar files inspected]`.
 - Module docs: `[module README/docs inspected]`.
 - Representative source: `[important source/entrypoint files inspected, or 'not inspected in lightweight mode']`.
 - Manifests/scripts/CI: `[manifests, scripts, workflows inspected, or 'not inspected in lightweight mode']`.
 - Local commit snapshot: `[raw/git-commits.json status and count]`.
 - Historical code-host snapshot: `[raw/github-facets.json or raw/gitlab-facets.json status and counts]`.
+```
 
-## Agent Consumption Rules
+### `.repo_memory/_plan.md`
 
-1. Read this file first, then inspect the live code path you plan to edit. Memory is an index, not proof.
-2. [Repo-specific safety or ownership rule].
-3. [Repo-specific preferred extension pattern].
-4. Treat PR/issue resources as historical/contextual; verify current behavior in code and tests.
+Create this temporary planning artifact after discovery and before final wiki writing. Use it to cluster repository concepts and choose natural page boundaries. Remove `_plan.md` before final validation; it is not part of the durable bundle.
 
-## Coding Memory Boundary
+```markdown
+# Repo Memory Wiki Plan
+
+## Candidate Domains Considered
+
+- [selected, merged, or skipped candidate domain] - [source evidence and decision].
 
-This repo memory is a cold-start repository map. Use it for module routing,
-historical PR/issue context, architecture boundaries, verification gates, and
-repository-specific conventions.
+## Intended Final Pages
 
-Runtime coding memory is narrower and should take precedence when it matches
-the current repo, module, API, behavior, lifecycle surface, ownership boundary,
-or failure mode. Use runtime coding memory for verified repair invariants,
-failed-attempt evidence, mutable-state ownership, callback/hook boundaries,
-adapter behavior, validation contracts, and other task-learned engineering
-lessons.
+| Page | Purpose | Source evidence | Boundary |
+|------|---------|-----------------|----------|
+| `repo-native-topic.md` | [Future-agent task this page routes.] | [Docs/source/tests/scripts inspected.] | [What belongs here and what belongs elsewhere.] |
 
-Do not treat repo memory, commits, PRs, or issues as implementation recipes.
-They are routing evidence and historical context. Always verify current
-behavior against live source and focused checks before editing.
+## Canonical Homes And Overlaps
 
-## Architecture Map
+- [Overlapping concept] belongs in `[page]`; link from `[other page]` instead of duplicating because [reason].
+
+## Weak Evidence And Verification Needs
+
+- [Claim/path/command] needs [specific verification] before final writing, or should be omitted.
+```
+
+### `.repo_memory/<repo-native-topic>.md`
+
+Create supporting conceptual pages after clustering inspected evidence. Name pages from repository vocabulary, not from this template. Use lowercase kebab-case filenames derived from product surfaces, runtime components, commands, protocols, adapters, workflows, data models, operations, or other durable repository concepts. Generic names are fallback names only when repository vocabulary gives no stronger topic. Every conceptual page must include frontmatter so validation can scan it.
+
+```markdown
+---
+schema: "repo_memory_wiki_page.v0.1"
+page_type: "architecture|workflow|data-model|integration|operation|testing|extension|domain"
+generated_at: "[ISO timestamp]"
+source_profile: "PROFILE.md"
+trust_state: "draft_wiki_page"
+---
 
-- `[module/path]`: [What it does, important entrypoints, how it relates to other modules].
-- `[module/path]`: [What it does, important entrypoints, how it relates to other modules].
+# [Human Documentation Title]
 
-## Runtime Flow
+## Purpose
 
-- [Main runtime/request/training/build flow].
-- [How modules communicate or hand off data].
-- [Where state, artifacts, configs, or generated outputs live].
+[Explain which future tasks should open this page and what decisions it helps route.]
 
-## Verification Gates
+## Key Paths
 
-- [Documentation-only verification].
-- [Syntax/static checks].
-- [Unit/smoke/integration checks].
-- [Expensive or environment-dependent checks and required services].
+| Path | Responsibility | When to inspect |
+|------|----------------|-----------------|
+| `path/to/file-or-dir` | [What it owns.] | [Task cue, symbol, command, or failure mode.] |
 
-## Resource Pointers
+## Flow Or Boundaries
 
-- Commit resource: `.repo_memory/resources/commits.md`.
-- PR resource: `.repo_memory/resources/prs.md`.
-- Issue resource: `.repo_memory/resources/issues.md`.
-- Raw local commit facets: `.repo_memory/raw/git-commits.json`.
-- Raw code-host facets: `.repo_memory/raw/github-facets.json` or `.repo_memory/raw/gitlab-facets.json`.
-- Mechanical preparation facts: `.repo_memory/raw/prepare-report.json`.
+[Explain the concept, lifecycle, dependency direction, or ownership boundary. Prefer short paragraphs and bullets over exhaustive API reference.]
 
-## Code Host Snapshot Notes
+## Verification
 
-- [Major merged PR themes].
-- [Recent local commit themes].
-- [Open PR themes and warning that they are not landed behavior].
-- [Issue clusters / user pain points].
+- [Fast command or source check relevant to this page.]
+- [Expensive or environment-dependent check, or say none identified.]
 
-## Retrieval Flow
+## Agent Notes
 
-1. Start here for module ownership, boundaries, and verification gates.
-2. Open the relevant module docs/source entrypoints for the target path.
-3. Search `resources/*.md` by module, file, symbol, branch, SHA, PR/MR number, or issue number when historical context matters.
-4. Open matched `resources/*.md` sections for compact human-readable commit/PR/issue routing.
-5. Use `raw/git-commits.json`, `raw/github-facets.json`, or `raw/gitlab-facets.json` only when compact resources are insufficient or a matched section points to a raw facet.
+- Treat this page as routing context and verify current behavior in live source before editing.
+- [One repo-specific caution, extension rule, or likely pitfall.]
 ```
 
 ### `.repo_memory/resources/commits.md`
@@ -141,6 +198,7 @@ Source: `.repo_memory/raw/git-commits.json`. Treat commits as local checkout his
 ## Commit [short_sha]: [title]
 
 - SHA: `[full sha]`
+- Evidence status: [One short sentence describing local-history evidence strength and whether current source was verified.]
 - Author: `[author name]`
 - Authored: `[ISO timestamp]`
 - Modules: `[semantic modules for human routing]`
@@ -157,6 +215,7 @@ Source: `.repo_memory/raw/git-commits.json`. Treat commits as local checkout his
 ## Commit [short_sha]: [title]
 
 - SHA: `...`
+- Evidence status: ...
 - Author: `...`
 - Authored: `...`
 - Modules: `...`
@@ -169,6 +228,24 @@ Source: `.repo_memory/raw/git-commits.json`. Treat commits as local checkout his
 - Raw lookup: `facetId=commit.abc1234`
 ```
 
+When commit history is disabled by policy, still write a disabled resource file:
+
+```markdown
+---
+schema: "repo_memory_commit_resource.v0.1"
+repo_full_name: "[owner/name or local repo name]"
+generated_at: "[ISO timestamp]"
+source: "history_disabled"
+resource_count: 0
+trust_state: "disabled_by_policy"
+raw_source: ""
+---
+
+# Commit Resource Snapshot
+
+No commit evidence was collected because historical evidence was disabled for this build. This is a collection-policy statement, not proof that the repository has no commits.
+```
+
 ### `.repo_memory/resources/prs.md`
 
 Use fixed-field sections, not Markdown tables. Every GitHub PR or GitLab MR needs a search-grade `Description` following the standard in `SKILL.md`. Do not paste the full raw summary; full raw summaries stay in `../raw/github-facets.json` or `../raw/gitlab-facets.json`.
@@ -191,6 +268,7 @@ Source: `.repo_memory/raw/github-facets.json` or `.repo_memory/raw/gitlab-facets
 ## PR/MR #[number]: [title]
 
 - State: `MERGED|OPEN|CLOSED` [include draft if applicable]
+- Evidence status: [One short sentence describing historical/current relevance and whether current source was verified.]
 - Branch: `base <- head`
 - Modules: `[semantic modules for human routing]`
 - Path modules: `[path prefixes from raw facets or current inspection]`
@@ -208,6 +286,7 @@ Source: `.repo_memory/raw/github-facets.json` or `.repo_memory/raw/gitlab-facets
 ## PR/MR #[number]: [title]
 
 - State: `...`
+- Evidence status: ...
 - Branch: `...`
 - Modules: `...`
 - Path modules: `...`
@@ -243,6 +322,7 @@ Source: `.repo_memory/raw/github-facets.json` or `.repo_memory/raw/gitlab-facets
 ## Issue #[number]: [title]
 
 - State: `OPEN|CLOSED`
+- Evidence status: [One short sentence describing issue evidence strength, relevance, and whether current source was verified.]
 - Modules: `[semantic modules for human routing]`
 - Path modules: `[path prefixes from linked PR facets or current inspection, or -]`
 - Description: [2-4 search-grade sentences: what user problem/request this issue explains, when future agents should open it, affected behavior/modules, symptoms/errors, search cues, and evidence strength]
@@ -268,3 +348,43 @@ Source: `.repo_memory/raw/github-facets.json` or `.repo_memory/raw/gitlab-facets
 - URL: ...
 - Raw lookup: `facetId=issue.123`
 ```
+
+### Disabled Or Unavailable Resource Files
+
+Use this pattern when historical evidence or provider evidence was intentionally not collected, unavailable, or degraded to local-only. Keep `resource_count: 0` and `raw_source: ""`; do not fabricate PRs, MRs, issues, or raw provider evidence. Use `source: "history_disabled"` when the entire history channel is disabled, `source: "provider_skipped_local_only"` when provider collection was skipped for a local-only build, and `source: "provider_unavailable"` when provider collection could not be completed.
+
+For PR/MR resources:
+
+```markdown
+---
+schema: "repo_memory_pr_resource.v0.1"
+repo_full_name: "[owner/name or local repo name]"
+generated_at: "[ISO timestamp]"
+source: "provider_skipped_local_only|provider_unavailable|history_disabled"
+resource_count: 0
+trust_state: "unavailable_local_only|disabled_by_policy"
+raw_source: ""
+---
+
+# Pull Request Resource Snapshot
+
+No provider evidence was collected for PRs/MRs in this build. This means PR/MR history is unavailable in the memory bundle; it does not mean the repository has no PRs or MRs.
+```
+
+For issue resources:
+
+```markdown
+---
+schema: "repo_memory_issue_resource.v0.1"
+repo_full_name: "[owner/name or local repo name]"
+generated_at: "[ISO timestamp]"
+source: "provider_skipped_local_only|provider_unavailable|history_disabled"
+resource_count: 0
+trust_state: "unavailable_local_only|disabled_by_policy"
+raw_source: ""
+---
+
+# Issue Resource Snapshot
+
+No provider evidence was collected for issues in this build. This means issue history is unavailable in the memory bundle; it does not mean the repository has no issues.
+```