research

set me up a wiki on my docker thanks

[Request interrupted by user for tool use]

does portainer have an api that can let you do that for me?

ptr_BUTNoStBp474NqAO1AZPxJnTeSlKHj3+bSjnAlwrzjo=   http://192.168.1.249:9000/

is this a wiki? how will this work. Can you update it with some of my current projects as examples

15qIEx9WDjuaUMsMNx1Cv4mDjUN7WcIS is token, i dont care if its in transcripts

737N8iMfeLbSLY0M4uiwb0h9FI4K8LM2

im not sure i like this.. [Image #1] why so many overviews? is this just how you made it or what. I think a wiki would be better for me to be honest. Maybe if you try titling things properly i can look again then choose

[Image: source: /home/megaproxy/.claude/image-cache/7ce8fe8c-98d1-4724-bd85-e3fc918b200c/1.png]

keep this running. but lets set up a wiki with a similar thing. if i need to make a api key before you post thats fine, but i want a similar setup. Pages based on projects with subpages and sections etc. Lots of documentation. this is why i think wiki might be better

wiki is much better, keep bookstack for now. ill remove it myself later if i fell. Can you go through all my projects, research etc, everything. set up a workflow so you can properly fan out. I want as much documentation, information, faq if needed, you know the deal i want to flush this out

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/subreddit-announcer (kind: project). Wiki base path: projects/subreddit-announcer. Display name: Subreddit Announcer.

READ FIRST (as much as exists): ~/claude/projects/subreddit-announcer/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/subreddit-announcer.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/subreddit-announcer", "name": "Subreddit Announcer", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/subreddit-announcer". Then 1-5 subpages under "projects/subreddit-announcer/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/rimlike (kind: project). Wiki base path: projects/rimlike. Display name: Rimlike.

READ FIRST (as much as exists): ~/claude/projects/rimlike/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/rimlike.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/rimlike", "name": "Rimlike", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/rimlike". Then 1-5 subpages under "projects/rimlike/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/tileforge (kind: project). Wiki base path: projects/tileforge. Display name: Tileforge.

READ FIRST (as much as exists): ~/claude/projects/tileforge/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/tileforge.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/tileforge", "name": "Tileforge", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/tileforge". Then 1-5 subpages under "projects/tileforge/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/openworld-coop (kind: project). Wiki base path: projects/lostways. Display name: Lostways.

READ FIRST (as much as exists): ~/claude/projects/openworld-coop/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/lostways.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/lostways", "name": "Lostways", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/lostways". Then 1-5 subpages under "projects/lostways/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/tiletopia (kind: project). Wiki base path: projects/tiletopia. Display name: Tiletopia.

READ FIRST (as much as exists): ~/claude/projects/tiletopia/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/tiletopia.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/tiletopia", "name": "Tiletopia", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/tiletopia". Then 1-5 subpages under "projects/tiletopia/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/h200-2x-llm-testing (kind: research). Wiki base path: research/h200-llm-testing. Display name: H200 LLM Testing.

READ FIRST (as much as exists): ~/claude/research/h200-2x-llm-testing/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/h200-llm-testing.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/h200-llm-testing", "name": "H200 LLM Testing", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/h200-llm-testing". Then 1-5 subpages under "research/h200-llm-testing/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/tavernkeep (kind: project). Wiki base path: projects/tavernkeep. Display name: Tavernkeep.

READ FIRST (as much as exists): ~/claude/projects/tavernkeep/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/tavernkeep.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/tavernkeep", "name": "Tavernkeep", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/tavernkeep". Then 1-5 subpages under "projects/tavernkeep/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/flex-block-grabber-20260525 (kind: research). Wiki base path: research/flex-block-grabber. Display name: Flex Block Grabber.

READ FIRST (as much as exists): ~/claude/research/flex-block-grabber-20260525/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/flex-block-grabber.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/flex-block-grabber", "name": "Flex Block Grabber", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/flex-block-grabber". Then 1-5 subpages under "research/flex-block-grabber/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/lostways-perforce (kind: project). Wiki base path: projects/lostways-perforce. Display name: Lostways Perforce.

READ FIRST (as much as exists): ~/claude/projects/lostways-perforce/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/lostways-perforce.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/lostways-perforce", "name": "Lostways Perforce", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/lostways-perforce". Then 1-5 subpages under "projects/lostways-perforce/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/quotebot (kind: project). Wiki base path: projects/quotebot. Display name: Quotebot.

READ FIRST (as much as exists): ~/claude/projects/quotebot/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/quotebot.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/quotebot", "name": "Quotebot", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/quotebot". Then 1-5 subpages under "projects/quotebot/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/claude-usage-widget (kind: project). Wiki base path: projects/claude-usage-widget. Display name: Claude Usage Widget.

READ FIRST (as much as exists): ~/claude/projects/claude-usage-widget/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/claude-usage-widget.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/claude-usage-widget", "name": "Claude Usage Widget", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/claude-usage-widget". Then 1-5 subpages under "projects/claude-usage-widget/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/unraid-hang-20260525 (kind: research). Wiki base path: research/unraid-freezes. Display name: Unraid Freezes.

READ FIRST (as much as exists): ~/claude/research/unraid-hang-20260525/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/unraid-freezes.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/unraid-freezes", "name": "Unraid Freezes", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/unraid-freezes". Then 1-5 subpages under "research/unraid-freezes/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/llm-box-uk (kind: research). Wiki base path: research/llm-box-uk. Display name: LLM Box UK.

READ FIRST (as much as exists): ~/claude/research/llm-box-uk/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/llm-box-uk.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/llm-box-uk", "name": "LLM Box UK", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/llm-box-uk". Then 1-5 subpages under "research/llm-box-uk/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/fab-free-watcher (kind: research). Wiki base path: research/fab-watcher. Display name: Fab Watcher.

READ FIRST (as much as exists): ~/claude/research/fab-free-watcher/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/fab-watcher.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/fab-watcher", "name": "Fab Watcher", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/fab-watcher". Then 1-5 subpages under "research/fab-watcher/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/zoetrope (kind: project). Wiki base path: projects/zoetrope. Display name: Zoetrope.

READ FIRST (as much as exists): ~/claude/projects/zoetrope/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/zoetrope.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/zoetrope", "name": "Zoetrope", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/zoetrope". Then 1-5 subpages under "projects/zoetrope/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/projects/lmstudio-mcp (kind: project). Wiki base path: projects/lmstudio-mcp. Display name: LM Studio MCP.

READ FIRST (as much as exists): ~/claude/projects/lmstudio-mcp/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/lmstudio-mcp.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "projects/lmstudio-mcp", "name": "LM Studio MCP", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "projects/lmstudio-mcp". Then 1-5 subpages under "projects/lmstudio-mcp/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/research/lm-studio-tuning-20260527 (kind: research). Wiki base path: research/lm-studio-tuning. Display name: LM Studio Tuning.

READ FIRST (as much as exists): ~/claude/research/lm-studio-tuning-20260527/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/lm-studio-tuning.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "research/lm-studio-tuning", "name": "LM Studio Tuning", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "research/lm-studio-tuning". Then 1-5 subpages under "research/lm-studio-tuning/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/ideas/monquigame (kind: idea). Wiki base path: ideas/monquigame. Display name: Monquigame.

READ FIRST (as much as exists): ~/claude/ideas/monquigame/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/monquigame.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "ideas/monquigame", "name": "Monquigame", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "ideas/monquigame". Then 1-5 subpages under "ideas/monquigame/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

You are documenting one folder of the user's personal dev work for their private Wiki.js wiki. Work folder: ~/claude/ideas/openworld-coop (kind: idea). Wiki base path: ideas/openworld-coop. Display name: Openworld Coop (design).

READ FIRST (as much as exists): ~/claude/ideas/openworld-coop/memory.md in full (for ideas folders read plan.md instead), CLAUDE.md, README.md, any docs/*.md or *.md design docs at the root, and run 'git log --oneline -15' (may not be a git repo — fine), plus 'ls -R' (or a depth-limited find) to understand layout. For large source trees just skim key entry points; do not read everything.

THEN write a JSON file to /tmp/wiki-fanout/openworld-coop.json. Build it with a python3 script using json.dump (never hand-write JSON with shell quoting). Shape:
{"basePath": "ideas/openworld-coop", "name": "Openworld Coop (design)", "status": "...", "oneLiner": "...", "pages": [{"path": "...", "title": "...", "description": "...", "tags": ["..."], "content": "...markdown..."}]}

PAGES: the first page MUST be the overview at path "ideas/openworld-coop". Then 1-5 subpages under "ideas/openworld-coop/..." as the material warrants. Pick from: tasks (open TODOs as checkboxes + standing warnings), design or architecture (key decisions WITH their rationale), setup or runbook (how to build/run/deploy, env vars, gotchas), faq (only if there are genuine recurring gotchas/questions answerable from the sources), log (condensed history of major milestones with dates). Rich active projects deserve 4-6 pages total; small or dormant ones 2-3. This wiki is meant to hold LOTS of documentation — be generous and thorough, but every sentence must be grounded in what you read.

STATUS: active = being worked on now or recently; needs-attention = blocked/awaiting an action; delivered = done and usable; dormant = paused/superseded; idea = brainstorm only. oneLiner: one sentence for the dashboard, mention the current phase or outcome.

TAGS per page: include the status tag plus 1-3 topical tags (e.g. ue5, tauri, llm, discord-bot, godot, hardware).

WIKI CONVENTIONS (must follow exactly):
- Page titles must be globally self-descriptive: "<Project> — Overview", "<Project> — Tasks", "<Project> — FAQ" etc. NEVER a bare "Overview" or "Tasks".
- The overview page content MUST start with a bold status line, e.g. "**Status: Active** — one-line situation summary." Allowed statuses: Active / Needs attention / Delivered / Dormant / Idea.
- Dates always YYYY-MM-DD. Today is undefined.
- Markdown. Use ## section headers generously, - [ ] for task checkboxes, code fences for commands/paths.
- The wiki is the orientation + documentation layer. Synthesize and organize; do NOT paste memory.md verbatim. Deep volatile detail stays in the repo — link to repo files by path instead of duplicating.
- NEVER invent facts. If something is unknown or unclear from the sources, say so or omit it. Ground every claim in what you read.
- Links between this folder's own pages use absolute wiki paths like /projects/foo/tasks.

Do NOT post anything to any wiki or network service. Just write the JSON file. Your structured output: name, basePath, status, oneLiner, pages (path+title list), jsonPath.

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/lmstudio-mcp.json. Source folder it was derived from: ~/claude/projects/lmstudio-mcp.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/lmstudio-mcp"; all other paths start with "projects/lmstudio-mcp/". No duplicate paths.
3. Every title is globally self-descriptive ("LM Studio MCP — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/lmstudio-mcp.
6. FACT SPOT-CHECK: open ~/claude/projects/lmstudio-mcp/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/quotebot.json. Source folder it was derived from: ~/claude/projects/quotebot.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/quotebot"; all other paths start with "projects/quotebot/". No duplicate paths.
3. Every title is globally self-descriptive ("Quotebot — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/quotebot.
6. FACT SPOT-CHECK: open ~/claude/projects/quotebot/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/claude-usage-widget.json. Source folder it was derived from: ~/claude/projects/claude-usage-widget.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/claude-usage-widget"; all other paths start with "projects/claude-usage-widget/". No duplicate paths.
3. Every title is globally self-descriptive ("Claude Usage Widget — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/claude-usage-widget.
6. FACT SPOT-CHECK: open ~/claude/projects/claude-usage-widget/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/fab-watcher.json. Source folder it was derived from: ~/claude/research/fab-free-watcher.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "research/fab-watcher"; all other paths start with "research/fab-watcher/". No duplicate paths.
3. Every title is globally self-descriptive ("Fab Watcher — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /research/fab-watcher.
6. FACT SPOT-CHECK: open ~/claude/research/fab-free-watcher/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/subreddit-announcer.json. Source folder it was derived from: ~/claude/projects/subreddit-announcer.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/subreddit-announcer"; all other paths start with "projects/subreddit-announcer/". No duplicate paths.
3. Every title is globally self-descriptive ("Subreddit Announcer — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/subreddit-announcer.
6. FACT SPOT-CHECK: open ~/claude/projects/subreddit-announcer/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/flex-block-grabber.json. Source folder it was derived from: ~/claude/research/flex-block-grabber-20260525.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "research/flex-block-grabber"; all other paths start with "research/flex-block-grabber/". No duplicate paths.
3. Every title is globally self-descriptive ("Flex Block Grabber — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /research/flex-block-grabber.
6. FACT SPOT-CHECK: open ~/claude/research/flex-block-grabber-20260525/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/tileforge.json. Source folder it was derived from: ~/claude/projects/tileforge.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/tileforge"; all other paths start with "projects/tileforge/". No duplicate paths.
3. Every title is globally self-descriptive ("Tileforge — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/tileforge.
6. FACT SPOT-CHECK: open ~/claude/projects/tileforge/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/llm-box-uk.json. Source folder it was derived from: ~/claude/research/llm-box-uk.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "research/llm-box-uk"; all other paths start with "research/llm-box-uk/". No duplicate paths.
3. Every title is globally self-descriptive ("LLM Box UK — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /research/llm-box-uk.
6. FACT SPOT-CHECK: open ~/claude/research/llm-box-uk/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/unraid-freezes.json. Source folder it was derived from: ~/claude/research/unraid-hang-20260525.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "research/unraid-freezes"; all other paths start with "research/unraid-freezes/". No duplicate paths.
3. Every title is globally self-descriptive ("Unraid Freezes — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /research/unraid-freezes.
6. FACT SPOT-CHECK: open ~/claude/research/unraid-hang-20260525/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/zoetrope.json. Source folder it was derived from: ~/claude/projects/zoetrope.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/zoetrope"; all other paths start with "projects/zoetrope/". No duplicate paths.
3. Every title is globally self-descriptive ("Zoetrope — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/zoetrope.
6. FACT SPOT-CHECK: open ~/claude/projects/zoetrope/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/h200-llm-testing.json. Source folder it was derived from: ~/claude/research/h200-2x-llm-testing.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "research/h200-llm-testing"; all other paths start with "research/h200-llm-testing/". No duplicate paths.
3. Every title is globally self-descriptive ("H200 LLM Testing — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /research/h200-llm-testing.
6. FACT SPOT-CHECK: open ~/claude/research/h200-2x-llm-testing/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/lostways-perforce.json. Source folder it was derived from: ~/claude/projects/lostways-perforce.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/lostways-perforce"; all other paths start with "projects/lostways-perforce/". No duplicate paths.
3. Every title is globally self-descriptive ("Lostways Perforce — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/lostways-perforce.
6. FACT SPOT-CHECK: open ~/claude/projects/lostways-perforce/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/tavernkeep.json. Source folder it was derived from: ~/claude/projects/tavernkeep.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/tavernkeep"; all other paths start with "projects/tavernkeep/". No duplicate paths.
3. Every title is globally self-descriptive ("Tavernkeep — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/tavernkeep.
6. FACT SPOT-CHECK: open ~/claude/projects/tavernkeep/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/lostways.json. Source folder it was derived from: ~/claude/projects/openworld-coop.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/lostways"; all other paths start with "projects/lostways/". No duplicate paths.
3. Every title is globally self-descriptive ("Lostways — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/lostways.
6. FACT SPOT-CHECK: open ~/claude/projects/openworld-coop/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/monquigame.json. Source folder it was derived from: ~/claude/ideas/monquigame.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "ideas/monquigame"; all other paths start with "ideas/monquigame/". No duplicate paths.
3. Every title is globally self-descriptive ("Monquigame — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /ideas/monquigame.
6. FACT SPOT-CHECK: open ~/claude/ideas/monquigame/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/rimlike.json. Source folder it was derived from: ~/claude/projects/rimlike.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/rimlike"; all other paths start with "projects/rimlike/". No duplicate paths.
3. Every title is globally self-descriptive ("Rimlike — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/rimlike.
6. FACT SPOT-CHECK: open ~/claude/projects/rimlike/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).

Quality-gate a wiki page bundle before publication. File: /tmp/wiki-fanout/tiletopia.json. Source folder it was derived from: ~/claude/projects/tiletopia.

CHECK:
1. File parses as JSON and matches the expected shape (basePath, name, status, oneLiner, pages[] each with path/title/description/tags/content).
2. First page's path == "projects/tiletopia"; all other paths start with "projects/tiletopia/". No duplicate paths.
3. Every title is globally self-descriptive ("Tiletopia — Overview" style, never a bare "Overview"/"Tasks"/"FAQ").
4. Overview content starts with a bold **Status: ...** line and the status word matches the JSON status field (needs-attention -> "Needs attention", etc.).
5. Dates are YYYY-MM-DD. Internal links use absolute wiki paths under /projects/tiletopia.
6. FACT SPOT-CHECK: open ~/claude/projects/tiletopia/memory.md (or plan.md for ideas) and verify 4-5 specific claims from the pages (repo URLs, decisions, numbers, statuses). Fix anything invented, stale-stated-as-current, or contradicted by the source. Watch especially for secrets/credentials leaking into page content — remove any.
7. Markdown sanity: headers, checkbox lists, code fences render correctly.

If anything fails, FIX the JSON file in place (python3, json load->modify->dump). Keep the author's content otherwise. Return ok (true if file is now publication-ready) and fixes (list of corrections you made, empty if none).