Wiki Research Engineering

Wiki Research: Engineering

Process #engineering items from the research queue using the 5-step research loop. Every claim gets a knowledge tier. Every page ends with Limitations.

Vault location

/app/data/vault/

When to skip the loop

If the topic is a quick factual lookup (a release note, a docs link, a single fact), use web_search (engine brave) directly, write a one-paragraph wiki page with a source link, and stop. The full loop is for topics that reward depth.

The 5-step loop

Each step has a gate. Do not advance until the gate is met.

1 — Define

Before searching, write three sentences:

• Assumption: what you currently believe is true about this topic
• Unknown: the specific thing you don't know yet, as a question with a verifiable answer
• Answer shape: what a good answer looks like (a comparison, a number with conditions, a framework, a yes/no with caveats)

Gate: a reader who hasn't seen the queue item could tell whether your output answered it.

2 — Triage

Identify the 1–3 source types most likely to answer the question. For engineering topics, priority order:

1. Official docs / changelogs / spec pages (use web_search with engine brave, then intelli_extract on the URL)
2. Recent conference talks, engineering blog posts from named organisations
3. Issue threads, RFCs, design docs (GitHub, W3C, IETF, etc.)
4. Adjacent context: wiki pages already in the vault (wiki/index.md)

Run 2–3 Brave queries with focused prompts. For each promising URL, use intelli_extract with a focusPrompt that names the specific question from Step 1.

Gate: you can name 2+ source URLs you will cite before writing the page.

3 — Query

Pull the answer from the triaged sources.

• Use intelli_extract to lift relevant sections from each source.
• If two sources disagree, capture both positions.
• If a source is older than 12 months and the field moves fast (browsers, security, AI tooling), flag it and search for a newer one.

Gate: every claim you plan to write has at least one source URL attached.

4 — Verify

For every claim, assign one tier:

• FACT — directly stated in a source, with citation
• LIKELY — consistent with sources but inferred or synthesised
• SPECULATIVE — your reasoning beyond what sources support
• UNKNOWN — neither you nor the sources say

For any FACT or LIKELY claim that drives a decision the user might act on (architecture choice, security posture, purchase, migration), run a second web_search to corroborate.

Gate: every claim has a tier. The reader knows which claims to trust and which to test further.

5 — Report

Write the wiki page using the format below. Append a Limitations section.

Wiki page format

---
tags: [#engineering]
last_researched: YYYY-MM-DD
---

# <Title>

> One-sentence summary.

## Define
- **Assumption:** ...
- **Unknown:** ...
- **Answer shape:** ...

## Findings

### <Section heading>

- **FACT:** <claim> [^1]
- **FACT:** <claim> [^2]
- **LIKELY:** <claim> [^1, 2]
- **SPECULATIVE:** <claim>

### <Section heading>
...

## Limitations
- What the sources did not cover
- Which claims were not independently verified and why
- What would change the answer

## Sources
[^1]: <url> — accessed YYYY-MM-DD
[^2]: <url> — accessed YYYY-MM-DD

Per-run workflow

1. Read RESEARCH_QUEUE.md in the vault root.
2. Find all unchecked items (- [ ]) under ## #engineering. If none (or only placeholder), stop — log nothing, do nothing.
3. For each real unchecked item, run the 5-step loop above.
4. Determine if a relevant wiki page already exists by reading wiki/index.md.
   • If yes: read it, update it with new findings, mark conflicts.
   • If no: create wiki/engineering/<slug>.md.
5. Update wiki/index.md — add or update the entry.
6. Mark the item done in RESEARCH_QUEUE.md: - [x] + — researched YYYY-MM-DD.
7. After all items, move [x] items into the ## Archive section.
8. Append one entry to wiki/log.md:

   ## [YYYY-MM-DD] ingest | research-queue #engineering | <topics> → <pages>
   

Rules

• Never edit raw/, Openclaw articles/, or personal stuff/ — read-only.
• Only write to wiki/ and RESEARCH_QUEUE.md.
• If a topic is too vague to define an Unknown, mark [x] with — skipped: too vague, clarify topic.
• Keep one page per concept. If research reveals two distinct concepts, create two pages.
• Today's date comes from system context.