backup materials and knowledge-base docs

This commit is contained in:
admin
2026-05-30 16:22:29 +08:00
commit 93e50e8fce
3024 changed files with 2994945 additions and 0 deletions

View File

@@ -0,0 +1,42 @@
# Literature Canvas Workflow
## Default output
- `Maps/literature.canvas`
## Purpose
Provide a default Obsidian literature graph that:
- keeps `Sources/Papers/` as the canonical paper-note surface,
- keeps `Knowledge/` as the canonical synthesis surface,
- visualizes paper-to-paper and paper-to-knowledge relationships,
- stays lightweight enough to refresh after each major Zotero ingestion.
## Default behavior
- Use paper-note frontmatter and wikilinks as the primary graph source.
- Use `Sources/Papers/*.md` and relevant `Knowledge/*.md` as file nodes.
- Create `.canvas` by default for literature ingestion and review workflows.
- Treat Mermaid or markdown graph notes as optional legacy companions, not the default graph artifact.
- Prefer argument-map structure with `paper`, `claim`, `method`, and `gap` nodes over raw all-to-all paper linking.
- Thin edges aggressively; keep only the main reasoning chain and a small number of explicit semantic paper-to-paper relations.
- Hide or down-rank side branches when they clutter the display graph.
## Refresh triggers
Refresh the literature canvas when:
- new Zotero-sourced paper notes are added,
- paper notes gain new `linked_knowledge` edges or meaningful wikilinks,
- knowledge synthesis notes are updated after a literature pass,
- a batch Zotero review or note-ingestion pass finishes,
- a full-collection normalization pass changes many paper-note relationships.
## Recommended command
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/obsidian-literature-workflow/scripts/build_literature_canvas.py" --cwd "$PWD"
```
## Display rule
- If a second lightweight showcase graph is useful, maintain `Maps/literature-main.canvas` as a filtered presentation copy rather than bloating the default working canvas.

View File

@@ -0,0 +1,45 @@
# CLAIM EXTRACTION
Claim extraction should produce reusable literature notes, not vague summaries.
## Extract at least these fields
For each paper or source note, identify:
- **Claim** — what the paper says it achieves or establishes
- **Claim type** — author claim, community consensus, or project interpretation
- **Claim strength** — speculative, observed, supported, or strong
- **Evidence** — the concrete support for that claim (dataset, metric, experiment, analysis)
- **Method** — the approach or mechanism behind the claim
- **Limitation** — where the claim may not hold
- **Contradicts / weakens** — evidence or conditions that reduce confidence in the claim
- **Project relevance** — why this matters for the current project
## Writing rules
- Write claims in plain, reusable language.
- Distinguish the author claim from your project interpretation.
- Do not copy entire abstract sentences when a shorter paraphrase is clearer.
- Pair every durable claim with at least one evidence anchor.
- Do not promote a claim strength without naming the evidence that justifies the stronger level.
## Minimal output shape
This `Key Claims` block is a paper-note projection of the shared Evidence Record contract. Preserve the same evidence anchor, limitation, contradiction, project relevance, and claim strength so downstream synthesis can map it back to the canonical evidence record.
```md
## Key Claims
- Claim: ...
- Claim type: author claim | community consensus | project interpretation
- Claim strength: speculative | observed | supported | strong
- Evidence: ...
- Method: ...
- Limitation: ...
- Contradicts / weakens: ...
- Project relevance: ...
```
## Promotion rule
If a claim is reusable across multiple papers or sources, promote it from a paper note into `Knowledge/` instead of leaving it stranded in `Sources/Papers/`.
Only promote claims that include both an evidence anchor and a claim strength. If the evidence is weak or indirect, keep the claim as `speculative` or `observed` and preserve the uncertainty.

View File

@@ -0,0 +1,26 @@
# Legacy Literature Map Workflow
This reference is kept for backwards compatibility only.
## Legacy output
- `Knowledge/Literature-Map.md`
## Current default
- Use `CANVAS-WORKFLOW.md` for the current default literature graph artifact.
- The default graph is now `Maps/literature.canvas`, not a Mermaid note.
- Keep this markdown workflow only when a note-based map is specifically requested or needed for compatibility.
## Refresh triggers
Refresh the markdown map only when:
- new Zotero-sourced paper notes are added,
- paper-note links or metadata materially change,
- a batch literature review finishes.
## Recommended command
```bash
python3 "${CLAUDE_PLUGIN_ROOT}/skills/obsidian-literature-workflow/scripts/build_literature_graph.py" --cwd "$PWD"
```

View File

@@ -0,0 +1,3 @@
# LITERATURE CANVAS
The default literature canvas lives at Maps/literature.canvas and should stay sparse, argument-oriented, and source-backed.

View File

@@ -0,0 +1,3 @@
# LITERATURE OVERVIEW
Literature overview notes summarize the current field view for the project and must link source paper notes.

View File

@@ -0,0 +1,3 @@
# METHOD TAXONOMY
Method taxonomy notes group methods across papers and should link each taxonomy entry back to supporting paper notes.

View File

@@ -0,0 +1,3 @@
# PAPER NOTE SCHEMA
Use a strong paper schema with metadata, project relevance, summary, claims, methods, evidence, limitations, connections, and open questions.

View File

@@ -0,0 +1,3 @@
# RESEARCH GAPS
Research gap notes must state the gap, why it matters, and which paper notes support it.