baram2584/MultiPhysicsVault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add wiki
Tests / Hermetic test suite (push) Has been cancelled
Details
Tests / Skill frontmatter validation (push) Has been cancelled
Details

Browse Source
This commit is contained in:
김경종
2026-05-28 17:16:48 +09:00
parent 665c5ab4e4
commit 4cc312954f
5693 changed files with 66683 additions and 4087 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/Wiki Map.canvas
+138 -36
View File
@@ -1,37 +1,139 @@
{
"nodes":[
{"id":"title","type":"text","text":"# 🧠 Cosmic Brain\n### Knowledge Map — Fibonacci Spiral\n*12 nodes at golden angle 137.5° — the sunflower pattern*","x":-280,"y":-301,"width":560,"height":141},
{"id":"c-idx","type":"file","file":"wiki/concepts/_index.md","x":120,"y":-40,"width":270,"height":80,"color":"2"},
{"id":"e-idx","type":"file","file":"wiki/entities/_index.md","x":-411,"y":209,"width":270,"height":80,"color":"6"},
{"id":"s-idx","type":"file","file":"wiki/sources/_index.md","x":-101,"y":-488,"width":270,"height":80,"color":"4"},
{"id":"dash","type":"file","file":"wiki/meta/dashboard.md","x":187,"y":372,"width":260,"height":108,"color":"5"},
{"id":"ov","type":"file","file":"wiki/overview.md","x":-702,"y":-141,"width":260,"height":80,"color":"5"},
{"id":"llm-wiki","type":"file","file":"wiki/concepts/LLM Wiki Pattern.md","x":401,"y":-381,"width":260,"height":80,"color":"2"},
{"id":"hot-c","type":"file","file":"wiki/concepts/Hot Cache.md","x":-313,"y":623,"width":260,"height":80,"color":"2"},
{"id":"hot-m","type":"file","file":"wiki/hot.md","x":-469,"y":-691,"width":260,"height":80,"color":"5"},
{"id":"comp","type":"file","file":"wiki/concepts/Compounding Knowledge.md","x":593,"y":227,"width":280,"height":80,"color":"2"},
{"id":"karp","type":"file","file":"wiki/entities/Andrej Karpathy.md","x":-891,"y":275,"width":260,"height":80,"color":"6"},
{"id":"log-m","type":"file","file":"wiki/log.md","x":235,"y":-822,"width":260,"height":80,"color":"5"},
{"id":"lbl-concepts","type":"text","text":"**💡 CONCEPTS**","x":420,"y":-460,"width":160,"height":40,"color":"2"},
{"id":"lbl-entities","type":"text","text":"**👤 ENTITIES**","x":-960,"y":195,"width":160,"height":40,"color":"6"},
{"id":"lbl-sources","type":"text","text":"**📄 SOURCES**","x":-200,"y":-580,"width":160,"height":40,"color":"4"},
{"id":"lbl-nav","type":"text","text":"**🗂️ NAVIGATION**","x":-560,"y":-790,"width":190,"height":40,"color":"5"},
{"id":"hub","type":"file","file":"wiki/index.md","x":-230,"y":-141,"width":350,"height":2095,"color":"5"}
],
"edges":[
{"id":"e-hub-cidx","fromNode":"hub","fromSide":"right","toNode":"c-idx","toSide":"left","label":"concepts"},
{"id":"e-hub-eidx","fromNode":"hub","fromSide":"bottom","toNode":"e-idx","toSide":"top","label":"entities"},
{"id":"e-hub-sidx","fromNode":"hub","fromSide":"top","toNode":"s-idx","toSide":"bottom","label":"sources"},
{"id":"e-hub-dash","fromNode":"hub","fromSide":"right","toNode":"dash","toSide":"left"},
{"id":"e-hub-ov","fromNode":"hub","fromSide":"left","toNode":"ov","toSide":"right"},
{"id":"e-hub-hot","fromNode":"hub","fromSide":"left","toNode":"hot-m","toSide":"right"},
{"id":"e-hub-log","fromNode":"hub","fromSide":"top","toNode":"log-m","toSide":"bottom"},
{"id":"e-cidx-llm","fromNode":"c-idx","fromSide":"right","toNode":"llm-wiki","toSide":"left"},
{"id":"e-cidx-hc","fromNode":"c-idx","fromSide":"bottom","toNode":"hot-c","toSide":"top"},
{"id":"e-cidx-comp","fromNode":"c-idx","fromSide":"right","toNode":"comp","toSide":"left"},
{"id":"e-eidx-karp","fromNode":"e-idx","fromSide":"left","toNode":"karp","toSide":"right"},
{"id":"e-llm-karp","fromNode":"llm-wiki","fromSide":"bottom","toNode":"karp","toSide":"top","toEnd":"none","color":"6","label":"originated by"},
{"id":"e-hc-hot","fromNode":"hot-c","fromSide":"left","toNode":"hot-m","toSide":"right","label":"implemented as"},
{"id":"e-comp-karp","fromNode":"comp","fromSide":"left","toNode":"karp","toSide":"right","toEnd":"none","color":"6"}
]
}
"nodes": [
{"id": "title", "type": "text", "text": "# Finite Element Wiki Map\nComputational mechanics source map with solid, shell, MITC4, and buckling threads", "x": -320, "y": -360, "width": 640, "height": 120, "color": "5"},
{"id": "index", "type": "file", "file": "wiki/index.md", "x": -160, "y": -160, "width": 320, "height": 160, "color": "5"},
{"id": "source", "type": "file", "file": "wiki/sources/Finite Element Procedures.md", "x": -720, "y": -160, "width": 320, "height": 120, "color": "4"},
{"id": "domain", "type": "file", "file": "wiki/domains/Computational Mechanics.md", "x": 400, "y": -160, "width": 320, "height": 120, "color": "6"},
{"id": "author", "type": "file", "file": "wiki/entities/Klaus-Jurgen Bathe.md", "x": -720, "y": 80, "width": 320, "height": 100, "color": "6"},
{"id": "fem", "type": "file", "file": "wiki/concepts/Finite Element Method.md", "x": 400, "y": 80, "width": 320, "height": 100, "color": "2"},
{"id": "models", "type": "file", "file": "wiki/concepts/Engineering Mathematical Models.md", "x": -720, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "disp", "type": "file", "file": "wiki/concepts/Displacement-Based Finite Element Formulation.md", "x": -360, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "iso", "type": "file", "file": "wiki/concepts/Isoparametric Finite Elements.md", "x": 0, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "mixed", "type": "file", "file": "wiki/concepts/Mixed Finite Element Formulations.md", "x": 360, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "nonlinear", "type": "file", "file": "wiki/concepts/Nonlinear Finite Element Analysis.md", "x": 720, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "solvers", "type": "text", "text": "## Solver Layer\nStatic, transient, and eigenvalue solution methods", "x": -360, "y": 520, "width": 680, "height": 90, "color": "3"},
{"id": "static", "type": "file", "file": "wiki/concepts/Static Equilibrium Equation Solvers.md", "x": -540, "y": 660, "width": 320, "height": 100, "color": "3"},
{"id": "time", "type": "file", "file": "wiki/concepts/Direct Time Integration Methods.md", "x": -180, "y": 660, "width": 320, "height": 100, "color": "3"},
{"id": "eigen", "type": "file", "file": "wiki/concepts/Finite Element Eigenproblem Solvers.md", "x": 180, "y": 660, "width": 320, "height": 100, "color": "3"},
{"id": "impl", "type": "file", "file": "wiki/concepts/Finite Element Program Implementation.md", "x": 540, "y": 660, "width": 320, "height": 100, "color": "3"},
{"id": "shell-source", "type": "file", "file": "wiki/sources/A Continuum Mechanics Based Four-Node Shell.md", "x": -1080, "y": -20, "width": 320, "height": 120, "color": "4"},
{"id": "dvorkin", "type": "file", "file": "wiki/entities/Eduardo N. Dvorkin.md", "x": -1080, "y": 160, "width": 320, "height": 100, "color": "6"},
{"id": "shell-element", "type": "file", "file": "wiki/concepts/Continuum Mechanics Based Four-Node Shell Element.md", "x": 760, "y": 80, "width": 320, "height": 100, "color": "2"},
{"id": "shear", "type": "file", "file": "wiki/concepts/Assumed Transverse Shear Strain Interpolation.md", "x": 1080, "y": 300, "width": 320, "height": 100, "color": "2"},
{"id": "tl-shell", "type": "file", "file": "wiki/concepts/Total Lagrangian Shell Formulation.md", "x": 1080, "y": 440, "width": 320, "height": 100, "color": "2"},
{"id": "mitc-source", "type": "file", "file": "wiki/sources/Four-Node-Quadrilateral-Shell-Element-MITC4.md", "x": -1080, "y": 360, "width": 320, "height": 120, "color": "4"},
{"id": "edita", "type": "file", "file": "wiki/entities/Edita Dvorakova.md", "x": -1440, "y": 520, "width": 320, "height": 100, "color": "6"},
{"id": "patzak", "type": "file", "file": "wiki/entities/Borek Patzak.md", "x": -1080, "y": 560, "width": 320, "height": 100, "color": "6"},
{"id": "oofem", "type": "file", "file": "wiki/entities/OOFEM.md", "x": -720, "y": 560, "width": 320, "height": 100, "color": "6"},
{"id": "mitc4", "type": "file", "file": "wiki/concepts/MITC4 Shell Element.md", "x": 760, "y": 560, "width": 320, "height": 100, "color": "2"},
{"id": "scordelis", "type": "file", "file": "wiki/concepts/Scordelis-Lo Shell Benchmark.md", "x": 1120, "y": 660, "width": 320, "height": 100, "color": "3"},
{"id": "mitc-study", "type": "file", "file": "wiki/sources/MITC Study Notes.md", "x": -1440, "y": 720, "width": 320, "height": 120, "color": "4"},
{"id": "mitc-kin", "type": "file", "file": "wiki/concepts/MITC Shell Kinematics.md", "x": 760, "y": 820, "width": 320, "height": 100, "color": "2"},
{"id": "gl-strain", "type": "file", "file": "wiki/concepts/Green-Lagrange Strain Linearization.md", "x": 1120, "y": 820, "width": 320, "height": 100, "color": "2"},
{"id": "newmark", "type": "file", "file": "wiki/concepts/Nonlinear Newmark-Beta Integration.md", "x": 400, "y": 820, "width": 320, "height": 100, "color": "3"},
{"id": "dyn-source", "type": "file", "file": "wiki/sources/Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method.md", "x": -1440, "y": 940, "width": 320, "height": 120, "color": "4"},
{"id": "hee-jun", "type": "file", "file": "wiki/entities/Hee Jun Lee.md", "x": -1440, "y": 1120, "width": 320, "height": 100, "color": "6"},
{"id": "inha", "type": "file", "file": "wiki/entities/Inha University.md", "x": -1080, "y": 1120, "width": 320, "height": 100, "color": "6"},
{"id": "blzpack", "type": "file", "file": "wiki/entities/BLZPACK.md", "x": -720, "y": 1120, "width": 320, "height": 100, "color": "6"},
{"id": "abaqus", "type": "file", "file": "wiki/entities/ABAQUS.md", "x": -360, "y": 1120, "width": 320, "height": 100, "color": "6"},
{"id": "dynamic-buckling", "type": "file", "file": "wiki/concepts/Dynamic Buckling Analysis.md", "x": 400, "y": 1040, "width": 320, "height": 100, "color": "2"},
{"id": "instability-region", "type": "file", "file": "wiki/concepts/Dynamic Instability Region.md", "x": 760, "y": 1040, "width": 320, "height": 100, "color": "2"},
{"id": "geom-stiff", "type": "file", "file": "wiki/concepts/Geometric Stiffness Matrix.md", "x": 1120, "y": 1040, "width": 320, "height": 100, "color": "2"},
{"id": "shell-review-source", "type": "file", "file": "wiki/sources/On-the-Finite-Element-Analysis-of-Shell-Structures.md", "x": -1800, "y": 1280, "width": 360, "height": 120, "color": "4"},
{"id": "phill-lee", "type": "file", "file": "wiki/entities/Phill-Seung Lee.md", "x": -1980, "y": 1460, "width": 320, "height": 100, "color": "6"},
{"id": "hyuk-noh", "type": "file", "file": "wiki/entities/Hyuk-Chun Noh.md", "x": -1620, "y": 1460, "width": 320, "height": 100, "color": "6"},
{"id": "basic-shell-model", "type": "file", "file": "wiki/concepts/Basic Shell Mathematical Model.md", "x": 400, "y": 1260, "width": 320, "height": 100, "color": "2"},
{"id": "shell-asymptotic", "type": "file", "file": "wiki/concepts/Shell Structure Asymptotic Behavior.md", "x": 760, "y": 1260, "width": 320, "height": 100, "color": "2"},
{"id": "shell-locking", "type": "file", "file": "wiki/concepts/Shell Locking Phenomenon.md", "x": 1120, "y": 1260, "width": 320, "height": 100, "color": "2"},
{"id": "uniform-conv", "type": "file", "file": "wiki/concepts/Uniform Optimal Convergence.md", "x": 760, "y": 1420, "width": 320, "height": 100, "color": "3"},
{"id": "shell-benchmarking", "type": "file", "file": "wiki/concepts/Shell Element Benchmark Testing.md", "x": 1120, "y": 1420, "width": 320, "height": 100, "color": "3"},
{"id": "solid-source", "type": "file", "file": "wiki/sources/Solid Element Notes.md", "x": -1800, "y": -160, "width": 340, "height": 120, "color": "4"},
{"id": "solid-linear", "type": "file", "file": "wiki/concepts/Isoparametric Linear Solid Elements.md", "x": -360, "y": 80, "width": 320, "height": 100, "color": "2"},
{"id": "solid-shape", "type": "file", "file": "wiki/concepts/Solid Element Shape Functions.md", "x": -360, "y": 480, "width": 320, "height": 100, "color": "2"},
{"id": "solid-b", "type": "file", "file": "wiki/concepts/Solid Element Strain-Displacement Matrix.md", "x": 0, "y": 480, "width": 320, "height": 100, "color": "2"},
{"id": "solid-k", "type": "file", "file": "wiki/concepts/Solid Element Stiffness Integration.md", "x": 360, "y": 480, "width": 320, "height": 100, "color": "3"},
{"id": "solid-inc", "type": "file", "file": "wiki/concepts/Incompatible Mode Solid Elements.md", "x": 720, "y": 480, "width": 320, "height": 100, "color": "3"}
],
"edges": [
{"id": "e-index-source", "fromNode": "index", "fromSide": "left", "toNode": "source", "toSide": "right", "label": "source"},
{"id": "e-index-domain", "fromNode": "index", "fromSide": "right", "toNode": "domain", "toSide": "left", "label": "domain"},
{"id": "e-source-author", "fromNode": "source", "fromSide": "bottom", "toNode": "author", "toSide": "top", "label": "author"},
{"id": "e-domain-fem", "fromNode": "domain", "fromSide": "bottom", "toNode": "fem", "toSide": "top", "label": "core method"},
{"id": "e-fem-models", "fromNode": "fem", "fromSide": "bottom", "toNode": "models", "toSide": "top"},
{"id": "e-fem-disp", "fromNode": "fem", "fromSide": "bottom", "toNode": "disp", "toSide": "top"},
{"id": "e-fem-iso", "fromNode": "fem", "fromSide": "bottom", "toNode": "iso", "toSide": "top"},
{"id": "e-fem-mixed", "fromNode": "fem", "fromSide": "bottom", "toNode": "mixed", "toSide": "top"},
{"id": "e-fem-nonlinear", "fromNode": "fem", "fromSide": "bottom", "toNode": "nonlinear", "toSide": "top"},
{"id": "e-nonlinear-static", "fromNode": "nonlinear", "fromSide": "bottom", "toNode": "static", "toSide": "top"},
{"id": "e-fem-time", "fromNode": "fem", "fromSide": "bottom", "toNode": "time", "toSide": "top"},
{"id": "e-fem-eigen", "fromNode": "fem", "fromSide": "bottom", "toNode": "eigen", "toSide": "top"},
{"id": "e-iso-impl", "fromNode": "iso", "fromSide": "bottom", "toNode": "impl", "toSide": "top"},
{"id": "e-index-shell-source", "fromNode": "index", "fromSide": "left", "toNode": "shell-source", "toSide": "right", "label": "source"},
{"id": "e-shell-source-dvorkin", "fromNode": "shell-source", "fromSide": "bottom", "toNode": "dvorkin", "toSide": "top", "label": "author"},
{"id": "e-shell-source-author", "fromNode": "shell-source", "fromSide": "right", "toNode": "author", "toSide": "left", "label": "co-author"},
{"id": "e-shell-source-shell", "fromNode": "shell-source", "fromSide": "right", "toNode": "shell-element", "toSide": "left", "label": "formulation"},
{"id": "e-fem-shell", "fromNode": "fem", "fromSide": "right", "toNode": "shell-element", "toSide": "left"},
{"id": "e-shell-shear", "fromNode": "shell-element", "fromSide": "right", "toNode": "shear", "toSide": "left", "label": "locking remedy"},
{"id": "e-shell-tl", "fromNode": "shell-element", "fromSide": "right", "toNode": "tl-shell", "toSide": "left", "label": "nonlinear kinematics"},
{"id": "e-tl-nonlinear", "fromNode": "tl-shell", "fromSide": "left", "toNode": "nonlinear", "toSide": "right"},
{"id": "e-index-mitc-source", "fromNode": "index", "fromSide": "left", "toNode": "mitc-source", "toSide": "right", "label": "source"},
{"id": "e-mitc-source-edita", "fromNode": "mitc-source", "fromSide": "bottom", "toNode": "edita", "toSide": "top", "label": "author"},
{"id": "e-mitc-source-patzak", "fromNode": "mitc-source", "fromSide": "bottom", "toNode": "patzak", "toSide": "top", "label": "author"},
{"id": "e-mitc-source-oofem", "fromNode": "mitc-source", "fromSide": "bottom", "toNode": "oofem", "toSide": "top", "label": "implementation"},
{"id": "e-mitc-source-mitc4", "fromNode": "mitc-source", "fromSide": "right", "toNode": "mitc4", "toSide": "left", "label": "element"},
{"id": "e-shell-mitc4", "fromNode": "shell-element", "fromSide": "bottom", "toNode": "mitc4", "toSide": "top", "label": "implementation thread"},
{"id": "e-shear-mitc4", "fromNode": "shear", "fromSide": "bottom", "toNode": "mitc4", "toSide": "top", "label": "MITC remedy"},
{"id": "e-mitc4-scordelis", "fromNode": "mitc4", "fromSide": "right", "toNode": "scordelis", "toSide": "left", "label": "benchmark"},
{"id": "e-oofem-impl", "fromNode": "oofem", "fromSide": "right", "toNode": "impl", "toSide": "left", "label": "code"},
{"id": "e-index-mitc-study", "fromNode": "index", "fromSide": "left", "toNode": "mitc-study", "toSide": "right", "label": "source"},
{"id": "e-mitc-study-mitc4", "fromNode": "mitc-study", "fromSide": "right", "toNode": "mitc4", "toSide": "left", "label": "derivation"},
{"id": "e-mitc-study-kin", "fromNode": "mitc-study", "fromSide": "right", "toNode": "mitc-kin", "toSide": "left", "label": "kinematics"},
{"id": "e-mitc-kin-shell", "fromNode": "mitc-kin", "fromSide": "top", "toNode": "shell-element", "toSide": "bottom", "label": "director model"},
{"id": "e-mitc-kin-gl", "fromNode": "mitc-kin", "fromSide": "right", "toNode": "gl-strain", "toSide": "left", "label": "linearization"},
{"id": "e-gl-tl", "fromNode": "gl-strain", "fromSide": "top", "toNode": "tl-shell", "toSide": "bottom", "label": "strain measure"},
{"id": "e-gl-nonlinear", "fromNode": "gl-strain", "fromSide": "top", "toNode": "nonlinear", "toSide": "bottom", "label": "tangent"},
{"id": "e-newmark-time", "fromNode": "newmark", "fromSide": "top", "toNode": "time", "toSide": "bottom", "label": "time integration"},
{"id": "e-newmark-nonlinear", "fromNode": "newmark", "fromSide": "top", "toNode": "nonlinear", "toSide": "bottom", "label": "Newton"},
{"id": "e-index-dyn-source", "fromNode": "index", "fromSide": "left", "toNode": "dyn-source", "toSide": "right", "label": "source"},
{"id": "e-dyn-source-author", "fromNode": "dyn-source", "fromSide": "bottom", "toNode": "hee-jun", "toSide": "top", "label": "author"},
{"id": "e-dyn-source-inha", "fromNode": "dyn-source", "fromSide": "bottom", "toNode": "inha", "toSide": "top", "label": "institution"},
{"id": "e-dyn-source-blzpack", "fromNode": "dyn-source", "fromSide": "bottom", "toNode": "blzpack", "toSide": "top", "label": "solver"},
{"id": "e-dyn-source-abaqus", "fromNode": "dyn-source", "fromSide": "bottom", "toNode": "abaqus", "toSide": "top", "label": "validation"},
{"id": "e-dyn-source-dynamic", "fromNode": "dyn-source", "fromSide": "right", "toNode": "dynamic-buckling", "toSide": "left", "label": "stability"},
{"id": "e-dynamic-region", "fromNode": "dynamic-buckling", "fromSide": "right", "toNode": "instability-region", "toSide": "left", "label": "output"},
{"id": "e-dynamic-geom", "fromNode": "dynamic-buckling", "fromSide": "right", "toNode": "geom-stiff", "toSide": "left", "label": "buckling tangent"},
{"id": "e-geom-tl", "fromNode": "geom-stiff", "fromSide": "top", "toNode": "tl-shell", "toSide": "bottom", "label": "derived by"},
{"id": "e-geom-eigen", "fromNode": "geom-stiff", "fromSide": "left", "toNode": "eigen", "toSide": "right", "label": "eigenproblem"},
{"id": "e-dynamic-mitc4", "fromNode": "dynamic-buckling", "fromSide": "top", "toNode": "mitc4", "toSide": "bottom", "label": "shell model"},
{"id": "e-blzpack-eigen", "fromNode": "blzpack", "fromSide": "right", "toNode": "eigen", "toSide": "left", "label": "Block Lanczos"},
{"id": "e-index-shell-review", "fromNode": "index", "fromSide": "left", "toNode": "shell-review-source", "toSide": "right", "label": "source"},
{"id": "e-shell-review-phill", "fromNode": "shell-review-source", "fromSide": "bottom", "toNode": "phill-lee", "toSide": "top", "label": "author"},
{"id": "e-shell-review-noh", "fromNode": "shell-review-source", "fromSide": "bottom", "toNode": "hyuk-noh", "toSide": "top", "label": "author"},
{"id": "e-shell-review-model", "fromNode": "shell-review-source", "fromSide": "right", "toNode": "basic-shell-model", "toSide": "left", "label": "model"},
{"id": "e-shell-review-asymptotic", "fromNode": "shell-review-source", "fromSide": "right", "toNode": "shell-asymptotic", "toSide": "left", "label": "thin shell behavior"},
{"id": "e-shell-review-locking", "fromNode": "shell-review-source", "fromSide": "right", "toNode": "shell-locking", "toSide": "left", "label": "failure mode"},
{"id": "e-shell-review-benchmark", "fromNode": "shell-review-source", "fromSide": "right", "toNode": "shell-benchmarking", "toSide": "left", "label": "testing"},
{"id": "e-basic-shell-element", "fromNode": "basic-shell-model", "fromSide": "top", "toNode": "shell-element", "toSide": "bottom", "label": "underlies"},
{"id": "e-basic-shell-kin", "fromNode": "basic-shell-model", "fromSide": "top", "toNode": "mitc-kin", "toSide": "bottom", "label": "director kinematics"},
{"id": "e-asymptotic-locking", "fromNode": "shell-asymptotic", "fromSide": "right", "toNode": "shell-locking", "toSide": "left", "label": "explains"},
{"id": "e-locking-shear", "fromNode": "shell-locking", "fromSide": "top", "toNode": "shear", "toSide": "bottom", "label": "remedied by"},
{"id": "e-locking-mitc4", "fromNode": "shell-locking", "fromSide": "top", "toNode": "mitc4", "toSide": "bottom", "label": "controlled by"},
{"id": "e-locking-uniform", "fromNode": "shell-locking", "fromSide": "bottom", "toNode": "uniform-conv", "toSide": "top", "label": "test criterion"},
{"id": "e-uniform-benchmark", "fromNode": "uniform-conv", "fromSide": "right", "toNode": "shell-benchmarking", "toSide": "left", "label": "measured by"},
{"id": "e-benchmark-scordelis", "fromNode": "shell-benchmarking", "fromSide": "top", "toNode": "scordelis", "toSide": "bottom", "label": "example"},
{"id": "e-benchmark-mitc4", "fromNode": "shell-benchmarking", "fromSide": "top", "toNode": "mitc4", "toSide": "bottom", "label": "validates"},
{"id": "e-index-solid-source", "fromNode": "index", "fromSide": "left", "toNode": "solid-source", "toSide": "right", "label": "source"},
{"id": "e-solid-source-linear", "fromNode": "solid-source", "fromSide": "right", "toNode": "solid-linear", "toSide": "left", "label": "solid element"},
{"id": "e-solid-source-shape", "fromNode": "solid-source", "fromSide": "right", "toNode": "solid-shape", "toSide": "left", "label": "shape functions"},
{"id": "e-solid-source-b", "fromNode": "solid-source", "fromSide": "right", "toNode": "solid-b", "toSide": "left", "label": "B matrix"},
{"id": "e-solid-source-k", "fromNode": "solid-source", "fromSide": "right", "toNode": "solid-k", "toSide": "left", "label": "stiffness"},
{"id": "e-solid-source-inc", "fromNode": "solid-source", "fromSide": "right", "toNode": "solid-inc", "toSide": "left", "label": "incompatible modes"},
{"id": "e-iso-solid-linear", "fromNode": "iso", "fromSide": "left", "toNode": "solid-linear", "toSide": "right", "label": "3D case"},
{"id": "e-solid-linear-disp", "fromNode": "solid-linear", "fromSide": "top", "toNode": "disp", "toSide": "bottom", "label": "u/v/w DOFs"},
{"id": "e-solid-linear-shape", "fromNode": "solid-linear", "fromSide": "bottom", "toNode": "solid-shape", "toSide": "top"},
{"id": "e-solid-shape-b", "fromNode": "solid-shape", "fromSide": "right", "toNode": "solid-b", "toSide": "left", "label": "Jacobian"},
{"id": "e-solid-b-k", "fromNode": "solid-b", "fromSide": "right", "toNode": "solid-k", "toSide": "left", "label": "B^T D B"},
{"id": "e-solid-inc-k", "fromNode": "solid-inc", "fromSide": "left", "toNode": "solid-k", "toSide": "right", "label": "augments"},
{"id": "e-solid-inc-mixed", "fromNode": "solid-inc", "fromSide": "top", "toNode": "mixed", "toSide": "bottom", "label": "enrichment pattern"}
]
}
wiki/canvases/claude-obsidian-presentation.canvas
-51
View File
@@ -1,51 +0,0 @@
{
"nodes":[
{"id":"zone-skills-1744041613","type":"group","x":-980,"y":-2640,"width":1820,"height":600,"color":"4","label":"Skills — Six Sub-Commands"},
{"id":"zone-demos-1744041634","type":"group","x":-980,"y":-990,"width":1820,"height":520,"color":"3","label":"Visual Demos"},
{"id":"zone-architecture-1744041623","type":"group","x":-980,"y":-2090,"width":1820,"height":500,"color":"2","label":"Architecture & Workflow"},
{"id":"zone-comparison-1744041630","type":"group","x":-980,"y":-1490,"width":1820,"height":440,"color":"1","label":"Wiki vs RAG — When to Use Which"},
{"id":"zone-overview-1744041606","type":"group","x":-980,"y":-3110,"width":1820,"height":420,"color":"5","label":"What Is claude-obsidian"},
{"id":"zone-hero-1744041605","type":"group","x":-980,"y":-3440,"width":1820,"height":280,"color":"6","label":"Hero"},
{"id":"title-hero-1744041601","type":"text","text":"# claude-obsidian\n\n**Claude Code × Obsidian** — Persistent, compounding knowledge base.\nEvery source you add makes the wiki smarter. No vector DB. No embeddings. Just markdown.\n\n*Skills: /wiki · /wiki-ingest · /wiki-query · /wiki-lint · /autoresearch · /canvas*","x":-960,"y":-3420,"width":600,"height":200,"color":"6"},
{"id":"img-cover-16x9-1744041602","type":"file","file":"wiki/meta/claude-obsidian-cover-16x9.png","x":-330,"y":-3420,"width":420,"height":216},
{"id":"img-gif-cover-1744041603","type":"file","file":"wiki/meta/claude-obsidian-gif-cover-16x9.gif","x":130,"y":-3420,"width":420,"height":216},
{"id":"img-gif-1x1-1744041604","type":"file","file":"wiki/meta/claude-obsidian-gif-1x1.gif","x":590,"y":-3420,"width":200,"height":200},
{"id":"text-what-1744041607","type":"text","text":"## What Is It?\n\nAn LLM wiki that **compounds** with every source you add. Originated by Andrej Karpathy.\n\nInstead of re-deriving from raw documents on every query (RAG), Claude reads each source, extracts what matters, and integrates it into a structured wiki — updating entity pages, noting contradictions, strengthening the synthesis.","x":-960,"y":-3090,"width":520,"height":200,"color":"5"},
{"id":"text-layers-1744041608","type":"text","text":"## Three Layers\n\n```\n.raw/ Layer 1 — immutable sources\nwiki/ Layer 2 — LLM knowledge base\nCLAUDE.md Layer 3 — maintenance schema\n```\n\nThe LLM owns Layer 2 entirely. It creates pages, updates them, maintains cross-references, and keeps everything consistent.","x":-400,"y":-3090,"width":460,"height":200,"color":"5"},
{"id":"text-why-1744041609","type":"text","text":"## Why It Works\n\nLLMs don't get bored.\n\nThe tedious part of maintaining a wiki is bookkeeping: cross-references, contradictions, stale summaries. Humans abandon wikis because maintenance cost grows faster than value.\n\n**With Claude: maintenance cost is near zero.**\nKnowledge compounds over time.","x":100,"y":-3090,"width":420,"height":200,"color":"5"},
{"id":"note-llm-wiki-pattern-1744041610","type":"file","file":"wiki/concepts/LLM Wiki Pattern.md","x":560,"y":-3090,"width":240,"height":100},
{"id":"note-compounding-1744041611","type":"file","file":"wiki/concepts/Compounding Knowledge.md","x":560,"y":-2960,"width":240,"height":100},
{"id":"note-hot-cache-1744041612","type":"file","file":"wiki/concepts/Hot Cache.md","x":560,"y":-2830,"width":240,"height":100},
{"id":"text-skills-header-1744041614","type":"text","text":"## Six Skills\n\n`/wiki` · `/wiki-ingest` · `/wiki-query` · `/wiki-lint` · `/autoresearch` · `/canvas`\n\nEach skill is a focused operation on the vault. Together they form a full knowledge lifecycle.","x":-960,"y":-2620,"width":1780,"height":80,"color":"4"},
{"id":"img-wiki-ingest-1744041615","type":"file","file":"_attachments/images/canvas/skill-wiki-ingest.png","x":-960,"y":-2510,"width":400,"height":225},
{"id":"img-wiki-query-1744041616","type":"file","file":"_attachments/images/canvas/skill-wiki-query.png","x":-520,"y":-2510,"width":400,"height":225},
{"id":"img-autoresearch-1744041617","type":"file","file":"_attachments/images/canvas/skill-autoresearch.png","x":-80,"y":-2510,"width":400,"height":225},
{"id":"img-wiki-canvas-1744041618","type":"file","file":"_attachments/images/canvas/skill-wiki-canvas.png","x":360,"y":-2510,"width":400,"height":225},
{"id":"text-ingest-desc-1744041619","type":"text","text":"**WIKI INGEST**\nDrop a source in `.raw/`, Claude reads it, extracts entities + concepts, updates 8–15 wiki pages, logs the ingest.","x":-960,"y":-2255,"width":400,"height":100},
{"id":"text-query-desc-1744041620","type":"text","text":"**WIKI QUERY**\nAsk any question. Claude reads the index, finds relevant pages, synthesizes with citations. Good answers get filed back.","x":-520,"y":-2255,"width":400,"height":100},
{"id":"text-autoresearch-desc-1744041621","type":"text","text":"**AUTORESEARCH**\nAutonomous web research loop. Searches, fetches, synthesizes, files. Based on Karpathy's autoresearch pattern.","x":-80,"y":-2255,"width":400,"height":100},
{"id":"text-canvas-desc-1744041622","type":"text","text":"**WIKI CANVAS**\nVisual layer. Add images, PDFs, and wiki notes to Obsidian canvas files with auto-positioning and zone management.","x":360,"y":-2255,"width":400,"height":100},
{"id":"text-arch-header-1744041624","type":"text","text":"## Lifecycle Flow\n\n```\nDrop source → /wiki-ingest → Wiki updated\n ↓\n /wiki-lint ←→ /wiki-query\n ↓\n /autoresearch\n ↓\n /canvas (visual)\n```","x":-960,"y":-2070,"width":560,"height":260,"color":"2"},
{"id":"img-workflow-loop-1744041625","type":"file","file":"wiki/meta/workflow-loop.gif","x":-360,"y":-2070,"width":236,"height":236},
{"id":"text-hot-cache-1744041626","type":"text","text":"## Hot Cache\n\n`wiki/hot.md` — a ~500-word context file updated after every ingest and session.\n\nLoaded automatically at conversation start. Gives Claude instant context without reading the full index.\n\n**Pattern:** hot → index → domain → page","x":100,"y":-2070,"width":420,"height":200,"color":"2"},
{"id":"img-graph-view-1744041627","type":"file","file":"wiki/meta/image-example-graph-view.png","x":560,"y":-2070,"width":370,"height":236},
{"id":"text-arch-stats-1744041628","type":"text","text":"**One source → 8–15 wiki pages touched**\n\nEntities, concepts, comparisons, questions — all updated in a single ingest pass.","x":-960,"y":-1780,"width":500,"height":80},
{"id":"img-wiki-graph-grow-1744041629","type":"file","file":"wiki/meta/wiki-graph-grow.gif","x":-420,"y":-1780,"width":236,"height":236},
{"id":"img-wiki-vs-rag-1744041631","type":"file","file":"_attachments/images/canvas/wiki-vs-rag-chart.svg","x":-960,"y":-1470,"width":800,"height":420},
{"id":"text-comparison-table-1744041632","type":"text","text":"## When Wiki Wins\n\n| Metric | LLM Wiki | RAG |\n|---|---|---|\n| Infrastructure | Markdown files | Vector DB |\n| Cost | Tokens only | Compute + storage |\n| Maintenance | Run a lint | Re-embed |\n| Scale limit | ~1000 pages | Millions |\n| Compounding | ✅ Yes | ❌ No |\n\n**Verdict:** Wiki wins at <1000 pages.\nFor millions of documents, use RAG.","x":-120,"y":-1470,"width":480,"height":360},
{"id":"note-wiki-vs-rag-1744041633","type":"file","file":"wiki/comparisons/Wiki vs RAG.md","x":400,"y":-1470,"width":380,"height":100},
{"id":"text-demos-header-1744041635","type":"text","text":"## See It In Action","x":-960,"y":-970,"width":300,"height":50,"color":"3"},
{"id":"img-welcome-canvas-1744041636","type":"file","file":"wiki/meta/welcome-canvas.gif","x":-960,"y":-900,"width":420,"height":236},
{"id":"img-wiki-map-1744041637","type":"file","file":"wiki/meta/image-example-wiki-map-view.png","x":-500,"y":-900,"width":316,"height":236},
{"id":"img-cover-square-1744041638","type":"file","file":"wiki/meta/claude-obsidian-cover-square.png","x":-40,"y":-900,"width":280,"height":280},
{"id":"text-install-1744041639","type":"text","text":"## Install\n\n```bash\nclaude plugin marketplace add \\\n AI-Marketing-Hub/claude-obsidian\n\nclaude plugin install claude-obsidian\n```\n\nRepo: `github.com/AI-Marketing-Hub/claude-obsidian`","x":280,"y":-900,"width":480,"height":200,"color":"3"},
{"id":"text-canvas-label-1744041640","type":"text","text":"Canvas Demo","x":-960,"y":-630,"width":420,"height":40},
{"id":"text-wikimap-label-1744041641","type":"text","text":"Wiki Map View","x":-500,"y":-630,"width":420,"height":40},
{"id":"text-cover-label-1744041642","type":"text","text":"Plugin Cover","x":-40,"y":-600,"width":280,"height":40}
],
"edges":[
{"id":"e-ingest-query-1744041650","fromNode":"img-wiki-ingest-1744041615","fromSide":"right","toNode":"img-wiki-query-1744041616","toSide":"left","color":"4","label":"builds"},
{"id":"e-query-auto-1744041651","fromNode":"img-wiki-query-1744041616","fromSide":"right","toNode":"img-autoresearch-1744041617","toSide":"left","color":"4","label":"grows"},
{"id":"e-auto-canvas-1744041652","fromNode":"img-autoresearch-1744041617","fromSide":"right","toNode":"img-wiki-canvas-1744041618","toSide":"left","color":"4","label":"visualizes"}
]
}
wiki/canvases/main.canvas
+2 -7
View File
@@ -1,12 +1,7 @@
{
"nodes":[
{"id":"zone-wiki-pages-1744033999","type":"group","x":-400,"y":320,"width":1000,"height":320,"color":"2","label":"Wiki Pages"},
{"id":"zone-default","type":"group","x":-400,"y":-140,"width":800,"height":400,"color":"4","label":"General"},
{"id":"note-llm-wiki-1744033901","type":"file","file":"wiki/concepts/LLM Wiki Pattern.md","x":80,"y":-120,"width":300,"height":100},
{"id":"text-insight-1744033945","type":"text","text":"## Key insight\n\nKnowledge compounds like interest.\nEvery ingest enriches 8–15 pages.","x":80,"y":0,"width":300,"height":220,"color":"5"},
{"id":"484d32f71e442aa0","type":"file","file":"Cosmic Brain Cover.png","x":-360,"y":360,"width":400,"height":206},
{"id":"a8f6d861b3c08664","type":"file","file":"Cosmic Brain Clean.gif","x":80,"y":360,"width":400,"height":206},
{"id":"title","type":"text","text":"# Visual Reference\n\nDrop images, PDFs, and notes here.","x":-440,"y":-360,"width":400,"height":120,"color":"6"}
{"id":"title","type":"text","text":"# Visual Reference\n\nDrop images, PDFs, and notes here.","x":-400,"y":-300,"width":400,"height":120,"color":"6"},
{"id":"zone-default","type":"group","label":"General","x":-400,"y":-140,"width":800,"height":400,"color":"4"}
],
"edges":[]
}
wiki/canvases/welcome.canvas
-27
View File
@@ -1,27 +0,0 @@
{
"nodes":[
{"id":"zone-input","type":"group","x":-680,"y":-360,"width":560,"height":560,"color":"4","label":"1 · Drop Your Sources"},
{"id":"zone-output","type":"group","x":480,"y":-360,"width":560,"height":560,"color":"6","label":"3 · Your Brain (Vault) Grows"},
{"id":"zone-process","type":"group","x":-60,"y":-360,"width":480,"height":560,"color":"2","label":"2 · I Process Everything"},
{"id":"gif-workflow","type":"file","file":"wiki/meta/workflow-loop.gif","x":-40,"y":-340,"width":440,"height":440},
{"id":"main-title","type":"text","text":"# 🧠 Claude Obsidian\n### Drop anything. I'll build your knowledge base.","x":-340,"y":-620,"width":840,"height":110},
{"id":"sub-title","type":"text","text":"Images · PDFs · Markdown · Transcripts · URLs — drag, drop, or paste. I handle the rest.","x":-340,"y":-500,"width":840,"height":54,"color":"5"},
{"id":"text-drop-images","type":"text","text":"## 📸 Paste any image here\n\nHere you can paste any images and I will take care of the rest.","x":-660,"y":-340,"width":520,"height":110,"color":"4"},
{"id":"text-drop-pdf","type":"text","text":"## 📄 Or drop PDF & Markdown files\n\nJust easy drag & drop — I'll extract everything.","x":-660,"y":60,"width":520,"height":100,"color":"4"},
{"id":"72b304484d8afa75","type":"file","file":"Cosmic Brain Clean.gif","x":-668,"y":-216,"width":536,"height":276},
{"id":"text-process","type":"text","text":"Reads sources → extracts entities & concepts → cross-references everything → files it all automatically.","x":-40,"y":110,"width":440,"height":80,"color":"2"},
{"id":"callout-1","type":"text","text":"💡 **8–15 wiki pages**\nper source ingested","x":-680,"y":440,"width":260,"height":80,"color":"4"},
{"id":"callout-2","type":"text","text":"⚡ **Hot cache**\ninstant session context","x":-400,"y":440,"width":260,"height":80,"color":"2"},
{"id":"callout-3","type":"text","text":"🔍 **Query anything**\nyou've ever added","x":-120,"y":440,"width":260,"height":80,"color":"5"},
{"id":"callout-4","type":"text","text":"🕸️ **Visual map**\nFibonacci graph layout","x":160,"y":440,"width":260,"height":80,"color":"6"},
{"id":"text-brain","type":"text","text":"## 🧠 I'll create a full map/brain for you\n\nEvery source compounds the knowledge base.","x":500,"y":-340,"width":520,"height":100,"color":"6"},
{"id":"text-result","type":"text","text":"Cross-referenced. Searchable. Gets richer every session.","x":500,"y":200,"width":520,"height":50,"color":"6"},
{"id":"gif-graph","type":"file","file":"wiki/meta/wiki-graph-grow.gif","x":568,"y":-225,"width":385,"height":385},
{"id":"cta-start","type":"text","text":"## 👉 Start here\n\n1. Read [[getting-started]] for a quick walkthrough\n2. Run `/wiki` in Claude Code to scaffold your vault\n3. Drop your first source into `.raw/` and say `ingest [filename]`","x":-140,"y":267,"width":560,"height":140,"color":"5"},
{"id":"025be16f290f1830","x":501,"y":280,"width":520,"height":293,"type":"file","file":"2026-04-07 14-19-00.mkv"}
],
"edges":[
{"id":"arrow-1","fromNode":"zone-input","fromSide":"right","toNode":"zone-process","toSide":"left","color":"4","label":"ingest"},
{"id":"arrow-2","fromNode":"zone-process","fromSide":"right","toNode":"zone-output","toSide":"left","color":"6","label":"builds"}
]
}
wiki/canvases/youtube-explainer.canvas
-251
View File
@@ -1,251 +0,0 @@
{
"nodes": [
{
"id": "zone-1", "type": "group", "label": "Beat 1 — Hook",
"x": 0, "y": 0, "width": 1920, "height": 1080, "color": "1"
},
{
"id": "z1-gif", "type": "file", "file": "claude-obsidian-gif-cover-16x9.gif",
"x": 20, "y": 20, "width": 960, "height": 540
},
{
"id": "z1-hook", "type": "text",
"text": "# Your AI forgets everything.\n\nEvery new chat starts from zero.\n\nYou re-explain the same context.\nAgain. And again.\n\n> [!warning] The real cost\n> Tokens burned. Momentum lost.\n> Good answers buried in chat history.",
"x": 1000, "y": 20, "width": 900, "height": 540, "color": "1"
},
{
"id": "z1-bridge", "type": "text",
"text": "## What if Claude just... knew?\n\nAnd got smarter every session?\n\nThat is what **claude-obsidian** does.",
"x": 20, "y": 580, "width": 1880, "height": 480, "color": "3"
},
{
"id": "z1-ref", "type": "text",
"text": "## SCRIPT — Beat 1: Hook (0:00–0:35)\n\n**Opening line:** \"Your AI forgets everything. Every single chat starts from zero.\"\n\n**Show:** animated GIF playing. Let it loop 2-3x.\n\n**Say:**\n- \"You know the feeling. You explain your project, your stack, your goals. Every. Single. Time.\"\n- \"What if Claude just knew? And got smarter every session?\"\n- \"That is what claude-obsidian does. Let me show you.\"\n\n**Transition:** pan down to Beat 2",
"x": 1960, "y": 0, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-2", "type": "group", "label": "Beat 2 — How it works",
"x": 0, "y": 1180, "width": 1920, "height": 1080, "color": "3"
},
{
"id": "z2-title", "type": "text",
"text": "# A wiki Claude writes for itself.",
"x": 20, "y": 1200, "width": 1880, "height": 80, "color": "3"
},
{
"id": "z2-img-a", "type": "file", "file": "_attachments/youtube/how-it-works.png",
"x": 20, "y": 1300, "width": 940, "height": 528
},
{
"id": "z2-img-b", "type": "file", "file": "_attachments/youtube/how-it-works-B.png",
"x": 980, "y": 1300, "width": 920, "height": 528
},
{
"id": "z2-flow-a", "type": "text",
"text": "## 💬 You chat\n\nAsk questions.\nWork on projects.\nExplore ideas.",
"x": 20, "y": 1848, "width": 580, "height": 192, "color": "5"
},
{
"id": "z2-flow-b", "type": "text",
"text": "## 📄 Claude files it\n\nPicks the note type.\nWrites wikilinks.\nUpdates the index.",
"x": 620, "y": 1848, "width": 580, "height": 192, "color": "4"
},
{
"id": "z2-flow-c", "type": "text",
"text": "## 💬 Next session\n\nClaude reads the wiki first.\nZero re-explaining.\nSmarter from the start.",
"x": 1220, "y": 1848, "width": 680, "height": 192, "color": "5"
},
{
"id": "z2-layers", "type": "text",
"text": "> [!tip] Key idea\n> **🔥 hot.md** — ~500 words, loaded every session automatically. Nearly free.\n> **🗂️ index.md** — full map of every page. Read when hot.md is not enough.\n> **📚 wiki/ pages** — the real knowledge. Only the relevant pages get read each session.",
"x": 20, "y": 2060, "width": 1880, "height": 180
},
{
"id": "z2-ref", "type": "text",
"text": "## SCRIPT — Beat 2: How it works (0:35–1:30)\n\n**Opening line:** \"Here is how it works.\"\n\n**Show:** the three-layer diagram image on the right\n\n**Say:**\n- \"claude-obsidian turns Obsidian into a wiki that Claude writes for itself.\"\n- \"Every chat you have, the good stuff gets filed. Next session Claude reads it first.\"\n- \"Three layers: hot.md loads every session — about 500 words, nearly free. Then index.md for the full map. Then individual wiki pages, only the ones that matter.\"\n- \"You stay in budget. The wiki keeps growing.\"\n\n**Show:** open wiki/hot.md — show it is small and focused\n\n**Transition:** \"So how do you actually build this wiki? Three commands.\"\n\n**Files to show:** `wiki/hot.md`, `wiki/index.md`",
"x": 1960, "y": 1180, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-3", "type": "group", "label": "Beat 3 — /save",
"x": 0, "y": 2360, "width": 1920, "height": 1080, "color": "4"
},
{
"id": "z3-title", "type": "text",
"text": "# /save — File the conversation into the wiki.",
"x": 20, "y": 2380, "width": 1880, "height": 80, "color": "4"
},
{
"id": "z3-img-a", "type": "file", "file": "_attachments/youtube/save-A.png",
"x": 20, "y": 2480, "width": 940, "height": 530
},
{
"id": "z3-img-b", "type": "file", "file": "_attachments/youtube/save-B.png",
"x": 980, "y": 2480, "width": 920, "height": 530
},
{
"id": "z3-bullets", "type": "text",
"text": "## What it does\n\n- Reads the full current chat\n- Picks the right note type: concept, question, source, or decision\n- Writes frontmatter and wikilinks automatically\n- Files the note in the correct wiki folder\n- Updates index.md, the session log, and hot.md\n\n> [!tip] Result\n> Good answers stop disappearing.",
"x": 20, "y": 3030, "width": 920, "height": 390
},
{
"id": "z3-example", "type": "text",
"text": "> [!example] Try it\n> `/save`\n>\n> or just: *save this as a concept note*\n\nClaude picks the type, writes the note,\nfiles it, and cross-links it. One command.",
"x": 960, "y": 3030, "width": 940, "height": 390, "color": "4"
},
{
"id": "z3-ref", "type": "text",
"text": "## SCRIPT — Beat 3: /save (1:30–2:45)\n\n**Opening line:** \"Command one: /save.\"\n\n**Show:** type `/save` in the terminal while on a chat with good content\n\n**Say:**\n- \"One command. Claude reads the whole conversation.\"\n- \"It picks the right note type — concept, question, decision, source. Writes frontmatter. Adds wikilinks to related pages. Files it in the right folder.\"\n- \"It also updates the index and the hot cache, so next session it's already loaded.\"\n- \"Good answers stop disappearing.\"\n\n**Show:** the new note open in Obsidian — show frontmatter and wikilinks\n\n**Transition:** \"But what if you want Claude to go do the research for you?\"\n\n**Files to show:** fresh page in `wiki/concepts/`\n**Skill source:** `skills/save/SKILL.md`",
"x": 1960, "y": 2360, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-4", "type": "group", "label": "Beat 4 — /autoresearch",
"x": 0, "y": 3540, "width": 1920, "height": 1080, "color": "4"
},
{
"id": "z4-title", "type": "text",
"text": "# /autoresearch — Autonomous research loop.",
"x": 20, "y": 3560, "width": 1880, "height": 80, "color": "4"
},
{
"id": "z4-img-a", "type": "file", "file": "_attachments/youtube/autoresearch-A.png",
"x": 20, "y": 3660, "width": 940, "height": 530
},
{
"id": "z4-img-b", "type": "file", "file": "_attachments/youtube/autoresearch-B.png",
"x": 980, "y": 3660, "width": 920, "height": 530
},
{
"id": "z4-bullets", "type": "text",
"text": "## What it does\n\n- Breaks the topic into 3 to 5 research angles\n- Runs web searches and fetches the best sources\n- Extracts claims, entities, and concepts\n- Runs a second pass to fill in the gaps it noticed\n- Files a synthesis page + source pages + concept pages, all cross-linked\n\n> [!tip] Result\n> Research that becomes a wiki, not a tab graveyard.",
"x": 20, "y": 4210, "width": 920, "height": 390
},
{
"id": "z4-example", "type": "text",
"text": "> [!example] Try it\n> `/autoresearch LLM wiki pattern`\n>\n> Output: 5 to 15 wiki pages, cross-linked, with citations.\n\nClaude works autonomously.\nYou get coffee.",
"x": 960, "y": 4210, "width": 940, "height": 390, "color": "4"
},
{
"id": "z4-ref", "type": "text",
"text": "## SCRIPT — Beat 4: /autoresearch (2:45–4:15)\n\n**Opening line:** \"Command two: /autoresearch. This one feels like magic.\"\n\n**Show:** type `/autoresearch claude-obsidian best practices` — let it start running\n\n**Say:**\n- \"It breaks the topic into research angles. Searches the web. Fetches real sources. Pulls out the key claims.\"\n- \"Then it runs a second pass to fill in the gaps it noticed the first time.\"\n- \"End result: 5 to 15 wiki pages. Cross-linked. With citations. In about 3 minutes.\"\n- \"You do not get a chat bubble that disappears. You get a permanent knowledge base.\"\n\n**Show:** Obsidian sidebar filling up with new pages while it runs\n\n**Transition:** \"And the third command is what you are actually watching right now.\"\n\n**Files to show:** `wiki/sources/`, `wiki/concepts/`\n**Skill source:** `skills/autoresearch/SKILL.md`",
"x": 1960, "y": 3540, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-5", "type": "group", "label": "Beat 5 — /canvas",
"x": 0, "y": 4720, "width": 1920, "height": 1080, "color": "4"
},
{
"id": "z5-title", "type": "text",
"text": "# /canvas — The visual layer of the wiki.",
"x": 20, "y": 4740, "width": 1880, "height": 80, "color": "4"
},
{
"id": "z5-img-a", "type": "file", "file": "_attachments/youtube/canvas-A.png",
"x": 20, "y": 4840, "width": 940, "height": 530
},
{
"id": "z5-img-b", "type": "file", "file": "_attachments/youtube/canvas-B.png",
"x": 980, "y": 4840, "width": 920, "height": 530
},
{
"id": "z5-bullets", "type": "text",
"text": "## What it does\n\n- Creates infinite visual boards inside Obsidian\n- Drops in images, text cards, PDFs, and wiki notes\n- Positions nodes automatically inside named zones\n- Uses JSON Canvas 1.0 — open standard, portable and future-proof\n- Pairs with /banana for AI-generated images on any beat\n\n> [!key-insight] Meta moment\n> This canvas you are watching right now was built with /canvas.",
"x": 20, "y": 5390, "width": 920, "height": 390
},
{
"id": "z5-example", "type": "text",
"text": "> [!example] Try it\n> `/canvas new youtube-video`\n> `/canvas add note LLM Wiki Pattern`\n> `/canvas add image _attachments/youtube/save-A.png`\n\nInstant visual board.\nObsidian-native. Shareable.",
"x": 960, "y": 5390, "width": 940, "height": 390, "color": "4"
},
{
"id": "z5-ref", "type": "text",
"text": "## SCRIPT — Beat 5: /canvas (4:15–5:30)\n\n**Opening line:** \"Command three: /canvas. And what you are watching right now is it.\"\n\n**Show:** zoom out on this full canvas — let them see all 7 zones laid out\n\n**Say:**\n- \"This is /canvas. It gives the wiki a visual layer.\"\n- \"Drop in images, text cards, wiki notes, PDFs. Claude positions everything automatically.\"\n- \"You can build explainers, mood boards, project maps, video scripts — like this one.\"\n- \"This canvas? Every zone, every node — built with /canvas.\"\n\n**Show live:** type `/canvas add note LLM Wiki Pattern` — watch a node appear\n\n**Transition:** \"So that is the three commands. Let me quickly show you how the memory system behind them works.\"\n\n**Skill source:** `skills/canvas/SKILL.md`",
"x": 1960, "y": 4720, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-6", "type": "group", "label": "Beat 6 — Under the hood",
"x": 0, "y": 5900, "width": 1920, "height": 1080, "color": "3"
},
{
"id": "z6-title", "type": "text",
"text": "# Under the hood — why token cost stays low as the wiki grows.",
"x": 20, "y": 5920, "width": 1880, "height": 80, "color": "3"
},
{
"id": "z6-graph", "type": "file", "file": "image-example-graph-view.png",
"x": 20, "y": 6020, "width": 920, "height": 518
},
{
"id": "z6-wikimap", "type": "file", "file": "image-example-wiki-map-view.png",
"x": 960, "y": 6020, "width": 940, "height": 518
},
{
"id": "z6-hot", "type": "text",
"text": "## 🔥 hot.md\nLoaded automatically every session.\n~500 words. Near-zero token cost.\nRecent context. What is coming next.",
"x": 20, "y": 6558, "width": 600, "height": 200, "color": "1"
},
{
"id": "z6-index", "type": "text",
"text": "## 🗂️ index.md\nOne-line summary of every wiki page.\nRead when hot.md is not enough.\nThe full map, compactly.",
"x": 640, "y": 6558, "width": 620, "height": 200, "color": "3"
},
{
"id": "z6-pages", "type": "text",
"text": "## 📚 wiki/ pages\nConcepts. Sources. Decisions. People.\nOnly the relevant pages get read.\nDeep knowledge, on demand.",
"x": 1280, "y": 6558, "width": 620, "height": 200, "color": "4"
},
{
"id": "z6-insight", "type": "text",
"text": "> [!key-insight] The wiki can grow to thousands of pages. Your token cost per session barely moves.",
"x": 20, "y": 6778, "width": 1880, "height": 162
},
{
"id": "z6-ref", "type": "text",
"text": "## SCRIPT — Beat 6: Under the hood (5:30–6:30)\n\n**Opening line:** \"So how does Claude actually remember things without blowing your token budget?\"\n\n**Show:** pan across — graph view left, wiki map right, three layers below\n\n**Say:**\n- \"Three layers. That is the whole system.\"\n- \"hot.md loads every session — about 500 words. Recent context. Nearly free.\"\n- \"index.md is the full map: one line per page. Claude reads it when hot.md is not enough.\"\n- \"Then the actual wiki pages — only the ones that matter for that session.\"\n- \"The wiki can grow to thousands of pages. Your bill barely moves.\"\n\n**Show:** `wiki/hot.md` and `wiki/index.md` briefly\n\n**Transition:** pan down to install",
"x": 1960, "y": 5900, "width": 600, "height": 1080, "color": "6"
},
{
"id": "zone-7", "type": "group", "label": "Beat 7 — Install + CTA",
"x": 0, "y": 7080, "width": 1920, "height": 1080, "color": "5"
},
{
"id": "z7-title", "type": "text",
"text": "# Install in 2 lines — Free. Open source. Works with Claude Code today.",
"x": 20, "y": 7100, "width": 1880, "height": 80, "color": "5"
},
{
"id": "z7-gif", "type": "file", "file": "claude-obsidian-gif-1x1.gif",
"x": 20, "y": 7200, "width": 480, "height": 480
},
{
"id": "z7-cover", "type": "file", "file": "claude-obsidian-cover-16x9.png",
"x": 520, "y": 7200, "width": 1380, "height": 480
},
{
"id": "z7-cmd", "type": "text",
"text": "```bash\nclaude plugin marketplace add AgriciDaniel/claude-obsidian\nclaude plugin install claude-obsidian@agricidaniel-claude-obsidian\n```",
"x": 20, "y": 7700, "width": 920, "height": 160
},
{
"id": "z7-links", "type": "text",
"text": "## Links\n\n- **GitHub**: github.com/AgriciDaniel/claude-obsidian\n- **Community**: skool.com/ai-marketing-hub-pro\n- **Website**: agricidaniel.com\n\n> [!tip] Subscribe\n> More Claude Code builds every week.",
"x": 960, "y": 7700, "width": 940, "height": 440, "color": "5"
},
{
"id": "z7-ref", "type": "text",
"text": "## SCRIPT — Beat 7: Install + CTA (6:30–8:00)\n\n**Opening line:** \"Installing takes literally two lines.\"\n\n**Show:** terminal — type both install commands live, slowly\n\n**Say:**\n- \"Copy these two lines. Paste. Done.\"\n- \"claude-obsidian is free, open source, and works with Claude Code right now.\"\n- \"GitHub link is in the description. Come join the Skool community — free tier, live sessions every week.\"\n- \"If this was useful, hit subscribe. I build with Claude Code every week.\"\n\n**End:** let the animated GIF loop while you close out.\n\n**Do NOT rush this beat.**",
"x": 1960, "y": 7080, "width": 600, "height": 1080, "color": "6"
}
],
"edges": [
{"id": "e-flow-ab", "fromNode": "z2-flow-a", "fromSide": "right", "toNode": "z2-flow-b", "toSide": "left", "fromEnd": "none", "toEnd": "arrow"},
{"id": "e-flow-bc", "fromNode": "z2-flow-b", "fromSide": "right", "toNode": "z2-flow-c", "toSide": "left", "fromEnd": "none", "toEnd": "arrow"},
{"id": "e-hot-index", "fromNode": "z6-hot", "fromSide": "right", "toNode": "z6-index", "toSide": "left", "fromEnd": "none", "toEnd": "arrow"},
{"id": "e-index-pages", "fromNode": "z6-index", "fromSide": "right", "toNode": "z6-pages", "toSide": "left", "fromEnd": "none", "toEnd": "arrow"}
]
}
wiki/concepts/Assumed Transverse Shear Strain Interpolation.md
+71
View File
@@ -0,0 +1,71 @@
---
type: concept
title: "Assumed Transverse Shear Strain Interpolation"
complexity: advanced
domain: computational-mechanics
aliases:
- assumed shear strain interpolation
- transverse shear tying
- shear locking remedy
created: 2026-05-28
updated: 2026-05-28
address: c-000020
tags:
- concept
- finite-element-method
- shell-elements
- locking
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Shell Locking Phenomenon]]"
- "[[Uniform Optimal Convergence]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[MITC4 Shell Element]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Mixed Finite Element Formulations]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Isoparametric Finite Elements]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
---
# Assumed Transverse Shear Strain Interpolation
## Definition
Assumed transverse shear strain interpolation replaces the shear strains implied directly by the displacement interpolation with a separately interpolated shear strain field chosen to avoid artificial stiffness in shell bending.
## How It Works
In the four-node shell paper, the transverse shear strain components are interpolated in convected coordinates from selected tying locations rather than taken directly from the standard displacement field everywhere in the element. This lets the element approximate the near-zero transverse shear strains required by thin-shell bending while preserving a low-order quadrilateral element.
The MITC4 source presents the same practical idea under the Mixed Interpolation of Tensorial Components name. Its assumed transverse shear strains are computed from values at edge-midpoint tying locations and then transformed back to Cartesian strain components.
The MITC study notes keep this as the motivating issue: direct shell interpolation locks in thin shells, so the transverse shear strain field must be treated separately from the rest of the displacement-derived strain field.
The Korean shell FE review generalizes the same idea: reducing selected strain interpolation can relieve locking, but the assumed field must still satisfy consistency and avoid spurious zero-energy behavior.
## Why It Matters
Standard displacement interpolation can cause shear locking: the element cannot represent the bending state without introducing parasitic transverse shear strain, so the computed shell becomes too stiff as thickness decreases. The assumed shear strain field is a targeted correction that keeps the four-node shell usable for thin shells without abandoning the economical element topology.
## Connections
- [[Continuum Mechanics Based Four-Node Shell Element]] uses this technique as a core formulation choice.
- [[MITC4 Shell Element]] names the same locking remedy as mixed interpolation of tensorial components.
- [[Mixed Finite Element Formulations]] provides a broader context for introducing extra or altered fields to satisfy constraints.
- [[Displacement-Based Finite Element Formulation]] explains the displacement-only path that can lock.
- [[Isoparametric Finite Elements]] explains the low-order quadrilateral mapping context.
## Sources
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
- [[MITC Study Notes]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Basic Shell Mathematical Model.md
+52
View File
@@ -0,0 +1,52 @@
---
type: concept
title: "Basic Shell Mathematical Model"
complexity: advanced
domain: computational-mechanics
aliases:
- basic shell model
- shell mathematical model
- degenerated shell mathematical model
created: 2026-05-28
updated: 2026-05-28
address: c-000043
tags:
- concept
- finite-element-method
- shell-elements
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[MITC Shell Kinematics]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Shell Structure Asymptotic Behavior]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Basic Shell Mathematical Model
## Definition
The basic shell mathematical model is a general shell model that represents bending, membrane, transverse shear, and their coupling through midsurface geometry and director-based kinematics.
## How It Works
The model defines a shell through a midsurface, thickness coordinate, covariant and contravariant base vectors, and a director normal to the midsurface. The displacement field is expressed as a midsurface displacement plus a through-thickness rotation term. From that kinematic description, the model derives strain terms and a variational equilibrium equation for the shell.
The paper emphasizes that this is the mathematical model underlying degenerated or continuum-mechanics-based shell finite elements. That makes it the bridge between three-dimensional continuum mechanics and practical shell elements such as [[Continuum Mechanics Based Four-Node Shell Element]] and [[MITC4 Shell Element]].
## Why It Matters
Shell FE errors cannot be diagnosed only at the mesh or solver level. If the analyst does not understand what shell mathematical model is being approximated, it is easy to misread a converged-looking result that is actually affected by locking or wrong asymptotic behavior.
## Connections
- [[MITC Shell Kinematics]] is a derivation-level implementation of director-vector shell kinematics.
- [[Shell Structure Asymptotic Behavior]] uses the shell model's bending and membrane energy terms to classify thin-shell limits.
- [[Shell Locking Phenomenon]] occurs when an element's interpolation space cannot approximate the relevant bending or membrane constraints of this model.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Compounding Knowledge.md
-69
View File
@@ -1,69 +0,0 @@
---
type: concept
title: "Compounding Knowledge"
complexity: basic
domain: knowledge-management
aliases:
- "Knowledge Compounding"
- "Persistent Synthesis"
created: 2026-04-07
updated: 2026-04-07
tags:
- concept
- knowledge-management
status: mature
related:
- "[[LLM Wiki Pattern]]"
- "[[Hot Cache]]"
- "[[Andrej Karpathy]]"
- "[[concepts/_index]]"
sources:
---
# Compounding Knowledge
The central insight behind the [[LLM Wiki Pattern]]: knowledge in a wiki compounds like interest in a bank. Every source added, every question answered, every analysis filed makes the wiki more valuable — not just by adding pages, but by enriching the connections between existing pages.
---
## Why Normal AI Chats Don't Compound
In a standard chat, knowledge is ephemeral. Each session starts fresh. Even if you upload the same documents repeatedly, the LLM re-derives the same insights from scratch. Nothing accumulates.
The same is true of most RAG systems: they index raw documents and retrieve chunks at query time. The retrieval gets the right fragments, but no synthesis is built up. Nothing is compiled. Ask the same complex question twice and you get the same assembly process twice.
---
## How Wiki Knowledge Compounds
When a new source arrives, the LLM doesn't just index it. It integrates it:
- Updates entity pages with new information
- Flags contradictions with existing claims
- Strengthens or challenges the evolving synthesis
- Adds cross-references from the new source to existing pages and back
The cross-references are already there next time. The contradictions have already been flagged. The synthesis already reflects everything that was read.
**The wiki is pre-compiled knowledge.** RAG re-compiles on every query.
---
## The Maintenance Problem
Wikis maintained by humans decay. The maintenance burden grows faster than the value — updating cross-references, keeping summaries current, noting when new data contradicts old claims. Humans abandon wikis because no one wants to do the bookkeeping.
LLMs don't get bored. They don't forget to update a cross-reference. The cost of maintenance is near zero. This is the practical reason the wiki pattern works: the entity that's best at the tedious maintenance work is the same entity that reads and writes the wiki.
---
## In Practice
One X user turned 383 scattered files and over 100 meeting transcripts into a compact wiki and dropped token usage by 95% when querying with Claude. The drop came from two sources: better navigation (index + hot cache vs. full document search) and pre-compiled synthesis (no re-deriving the same insights from scratch).
---
## Connections
See [[LLM Wiki Pattern]] for the full architecture.
See [[Hot Cache]] for the session context mechanism.
See [[Andrej Karpathy]] for the origin of this framing.
wiki/concepts/Continuum Mechanics Based Four-Node Shell Element.md
+72
View File
@@ -0,0 +1,72 @@
---
type: concept
title: "Continuum Mechanics Based Four-Node Shell Element"
complexity: advanced
domain: computational-mechanics
aliases:
- four-node shell element
- Dvorkin-Bathe shell element
- continuum mechanics shell element
created: 2026-05-28
updated: 2026-05-28
address: c-000019
tags:
- concept
- finite-element-method
- shell-elements
- nonlinear-analysis
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Basic Shell Mathematical Model]]"
- "[[Shell Locking Phenomenon]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC4 Shell Element]]"
- "[[Scordelis-Lo Shell Benchmark]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
- "[[Total Lagrangian Shell Formulation]]"
- "[[Isoparametric Finite Elements]]"
- "[[Nonlinear Finite Element Analysis]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
---
# Continuum Mechanics Based Four-Node Shell Element
## Definition
A continuum-mechanics-based four-node shell element is a quadrilateral shell finite element whose behavior is derived from the three-dimensional continuum virtual work statement rather than from a specialized plate or shell theory.
## How It Works
The element represents shell geometry through a general four-node, non-flat quadrilateral description. It uses convected coordinates and a three-dimensional constitutive setting, while constraining the shell kinematics so the element can model thin and thick shells efficiently. The paper's central practical modification is a separate interpolation of transverse shear strains, which prevents the element from becoming overly stiff in thin-shell bending.
The MITC4 implementation paper restates this lineage in an implementation-focused form: the four-node quadrilateral shell is treated as a three-dimensional continuum description degenerated to shell behavior, with all element degrees of freedom concentrated at the four vertices.
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] names the [[Basic Shell Mathematical Model]] as the underlying model for continuum-mechanics-based shell finite elements. That source makes the element's locking behavior a consequence of how well the discretization can approximate the model's bending, membrane, and transverse shear strain spaces.
## Why It Matters
Four-node shell elements are attractive in large structural models because they are computationally economical, but low-order shell elements can lock, distort poorly, or admit spurious modes. This formulation shows how a low-order element can remain useful for nonlinear shell analysis when the shear strain field and nonlinear kinematics are handled carefully.
## Validation Thread
The source tests the element against simple patch and rigid-body checks, classical shell benchmarks such as the Scordelis-Lo roof and pinched cylinder, large-deflection cantilever behavior, shallow spherical shell response, stiffened plate buckling, and elastoplastic circular plate response.
The MITC4 source adds an [[OOFEM]] implementation thread, including patch tests and the [[Scordelis-Lo Shell Benchmark]] as the main convergence demonstration.
## Connections
- [[Assumed Transverse Shear Strain Interpolation]] is the locking remedy inside the element.
- [[Total Lagrangian Shell Formulation]] is the nonlinear kinematic framework used for large displacement and rotation response.
- [[Isoparametric Finite Elements]] supplies the mapping and integration context.
- [[Nonlinear Finite Element Analysis]] supplies the incremental solution context.
## Sources
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Direct Time Integration Methods.md
+59
View File
@@ -0,0 +1,59 @@
---
type: concept
title: "Direct Time Integration Methods"
complexity: advanced
domain: computational-mechanics
aliases:
- finite element dynamics
- direct integration
- Newmark method
created: 2026-05-28
updated: 2026-05-28
address: c-000014
tags:
- concept
- finite-element-method
- dynamics
status: current
related:
- "[[Finite Element Method]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[Nonlinear Newmark-Beta Integration]]"
- "[[Dynamic Buckling Analysis]]"
- "[[Finite Element Eigenproblem Solvers]]"
sources:
- "[[Finite Element Procedures]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Direct Time Integration Methods
## Definition
Direct time integration methods advance finite element equilibrium equations through time without necessarily transforming the problem into modal coordinates.
## How It Works
Dynamic finite element systems include mass, damping, stiffness, and time-dependent loading. The source covers central difference, Houbolt, Newmark, and Bathe methods, then analyzes approximation, load operators, stability, accuracy, numerical damping, and coupling of different integration operators.
The MITC study notes add a focused nonlinear Newmark-beta derivation: Newton iteration is used at each time step, and Newmark relations express acceleration and velocity increments through the displacement increment.
The dynamic buckling thesis uses time-dependent axial compression as the loading context. It connects dynamic response, natural frequency, and buckling instability boundaries rather than treating time integration as a standalone transient solve.
## Why It Matters
Time integration choices control stability, phase accuracy, numerical damping, and computational cost. Explicit methods can be efficient for very small stable time steps; implicit methods are more expensive per step but can support larger steps and nonlinear equilibrium iterations.
## Connections
- [[Finite Element Eigenproblem Solvers]] supports modal superposition and vibration analysis.
- [[Nonlinear Finite Element Analysis]] couples time integration with nonlinear iteration.
- [[Nonlinear Newmark-Beta Integration]] is the specific implicit nonlinear dynamics workflow extracted from the MITC notes.
- [[Finite Element Heat Transfer and Field Problems]] uses related transient integration ideas for first-order field equations.
## Sources
- [[Finite Element Procedures]]
- [[MITC Study Notes]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Displacement-Based Finite Element Formulation.md
+60
View File
@@ -0,0 +1,60 @@
---
type: concept
title: "Displacement-Based Finite Element Formulation"
complexity: advanced
domain: computational-mechanics
aliases:
- displacement formulation
- displacement method
created: 2026-05-28
updated: 2026-05-28
address: c-000008
tags:
- concept
- finite-element-method
- structural-mechanics
status: current
related:
- "[[Finite Element Method]]"
- "[[Isoparametric Finite Elements]]"
- "[[Mixed Finite Element Formulations]]"
- "[[Solid Element Notes]]"
- "[[Solid Element Strain-Displacement Matrix]]"
- "[[Solid Element Stiffness Integration]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Solid Element Notes]]"
---
# Displacement-Based Finite Element Formulation
## Definition
The displacement-based finite element formulation uses nodal displacements as the primary unknowns and derives element and global equilibrium equations from a virtual work, energy, or variational statement.
## How It Works
Element displacement fields are interpolated from nodal degrees of freedom. Strains are computed from displacement gradients, stresses from constitutive laws, and element stiffness matrices from the strain-displacement and material matrices. Element contributions are assembled into the global equilibrium system, commonly represented in linear static form as `K u = R`.
## Why It Matters
This is the main formulation path for linear solid and structural mechanics in the source. It is direct and broadly useful, but it has limits for incompressibility, locking, and constraints, which motivates [[Mixed Finite Element Formulations]].
The four-node shell paper gives a concrete locking example: direct displacement interpolation can impose nonphysical transverse shear strains in thin-shell bending, motivating [[Assumed Transverse Shear Strain Interpolation]].
[[Solid Element Notes]] gives the corresponding 3D continuum path: interpolate nodal translations, compute small strains with the solid `B` matrix, apply the Hooke-law `D` matrix, and integrate `B^T D B` over the element volume.
## Practical Checks
- Does the interpolation reproduce rigid-body motion and constant strain states where required?
- Are displacement boundary conditions imposed consistently?
- Are stresses recovered in a way that reflects the approximation quality?
- Does mesh refinement improve the relevant response quantities?
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[Solid Element Notes]]
wiki/concepts/DragonScale Memory.md
-295
View File
@@ -1,295 +0,0 @@
---
type: concept
title: "DragonScale Memory"
address: c-000001
complexity: advanced
domain: knowledge-management
aliases:
- "DragonScale"
- "DragonScale Architecture"
- "Fractal Memory"
created: 2026-04-23
updated: 2026-04-24
tags:
- concept
- knowledge-management
- memory
- architecture
- fractal
status: proposed
related:
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[Hot Cache]]"
- "[[concepts/_index]]"
sources:
---
# DragonScale Memory
A memory-layer design for LLM wiki vaults, inspired by the Heighway dragon curve. Four mechanisms (fold operator, deterministic page addresses, semantic tiling, boundary-first autoresearch) give an LLM-maintained wiki a principled way to grow, compact, and stay coherent. The dragon curve is a design-justification device, not a reasoning architecture.
> **Status: v0.4 2026-04-24.** All four mechanisms shipped as opt-in features. Phase 0 (spec) + Phase 1 (wiki-fold skill, dry-run verified) + Phase 2 (address MVP) + Phase 3 (semantic tiling) + Phase 3.5/3.6 (hardening) + Phase 4 (boundary-first autoresearch). See Review History for the progression.
---
## Scope
DragonScale is a **memory architecture**: it governs how a wiki grows, compacts, addresses its pages, and checks for duplicates. It is **not a search, planning, or reasoning algorithm.** Agent reasoning uses existing patterns (Tree of Thoughts with BFS/DFS/beam search; Yao et al. 2023).
**Honest disclaimer**: memory-layer choices are never neutral with respect to reasoning. What the vault surfaces, and in what order, shapes what the model sees. Long-context performance is position-sensitive (Liu et al. 2023, *Lost in the Middle*), and MemGPT's premise is that paging policy affects task success (Packer et al. 2023). One of the four mechanisms below (boundary-first autoresearch) explicitly crosses into agenda control; it is included deliberately and marked as such.
---
## The Core Analogy
Four dragon-curve properties map onto memory-system patterns already validated in adjacent fields. The word is *analogue*, not *identity*.
| Dragon curve property | Memory analogue | Strength of analogy |
|---|---|---|
| Paper-folding recursion: `D_{n+1} = D_n · R · swap(reverse(D_n))` | Hierarchical rollup / materialized summary with exponential fanout | Loose. Shares exponential batch structure, not compaction semantics. |
| Turn derivable from bits of `n` (regular paperfolding sequence, OEIS A014577) | Deterministic page addresses as organizational convention (MVP is a creation-order counter, not a true content hash) | Loose. Deterministic addressing is useful independent of the dragon. |
| Tiling / no self-intersection | Canonical-home coverage: one concept, one page | Medium. Dedup lint enforces this mechanically. |
| Boundary dim ≈ 1.523627 vs interior dim 2 | Agent attention weighted toward frontier pages | Aesthetic. The fractal dimension number does no load-bearing work. |
The curve is useful for deciding *which knobs to tighten and why*, not as a math proof that any given mechanism is optimal.
---
## Mechanism 1 — Fold Operator
After a batch of ingests, run a fold: produce a meta-page summarizing the batch, link children back, update the index. Folds stack: after enough level-`k` folds accumulate, a level-`k+1` fold produces a super-summary.
This is a **hierarchical rollup**, loosely similar to LSM-tree compaction but with important differences.
**What it shares with LSM compaction:**
- Exponential batch fanout across levels (like LevelDB's fixed level-size ratio, typically 10× per level in leveled mode)
- Periodic consolidation rather than per-write work
**What it does NOT inherit from LSM:**
- No sorted-key semantics (pages have semantic, not key-ordered, identity)
- No SSTable/memtable distinction, no tombstones, no Bloom filters
- No write-amplification arithmetic; no read-path acceleration
- **Folds are additive**: children remain in place. LSM compaction rewrites and deletes. A DragonScale fold is closer to a materialized view than a compaction.
**Trigger options:**
- `2^k` entry count (k=4 ⇒ every 16 log entries). Simple to implement; straightforward level math; ignores page size and novelty.
- **Adaptive trigger (preferred for production)**: token budget (e.g., fold when unfolded batch exceeds N tokens), novelty score (average embedding distance from existing summaries), or staleness age (last fold > T days). Phase 1 will implement entry-count for MVP; adaptive triggers are a follow-up.
**Invariants:**
- Idempotent on the same range (re-running is a no-op).
- Reversible (children stay; a fold is additive).
- Level-bounded: with entry-count trigger `2^k`, fold depth is at most `⌈log₂(N)⌉` above leaf pages. Derived, not empirical.
---
## Mechanism 2 — Deterministic Page Addresses
Every new page gets a stable `address` field in frontmatter. The Phase 2 MVP uses a simple creation-order counter:
```yaml
address: c-000042
```
Format: `c-<6-digit-counter>`. `c-` means "creation-order counter." Zero-padded.
**Future extension** (documented, not shipped in Phase 2):
- Fold-relative path: `f1.2/c-000042` once folds exist, where `f1.2` encodes the fold-tree lineage.
- Content hash suffix: `c-000042:h7f3c2` once the hash-rotation policy is decided.
**What Phase 2 MVP gives:**
- Uniqueness: counter is monotonically increasing; deleted pages' addresses are retired, never reused.
- Stability: never changes across content edits.
- Determinism: derivable from the counter state at `.vault-meta/address-counter.txt`.
- Ordering: preserves creation sequence.
**What this does NOT give (renamed "content-addressable paths" was misleading in v0.1):**
- **No content-addressability in the MVP.** The Phase 2 address is a sequence counter, not a content hash. Renaming this mechanism from "content-addressable paths" to "deterministic page addresses" is more honest about what actually ships.
- **No prompt cache benefit** (already corrected in v0.1 → v0.2). Per Anthropic docs, cache hits require byte-identical prefixes; an address field in frontmatter only helps if the frontmatter itself is inside a cached block AND stays byte-identical. Stable prefixes, not addresses, drive cache hits.
**Phase 2 exclusions** (all deferred):
- Backfill of legacy pre-Phase-2 pages (will use `l-` prefix with its own counter).
- Fold-ancestry bit prefix (requires committed folds from a future fold-of-folds skill).
- Content hash suffix (rotation policy unresolved; see limitations).
**Implementation** (Phase 2, shipped):
- `scripts/allocate-address.sh`: flock-guarded atomic allocator. All counter reads/writes go through this script; direct Write/Edit on `.vault-meta/address-counter.txt` is prohibited (would fire PostToolUse hook).
- `skills/wiki-ingest/SKILL.md` → Address Assignment section: opt-in feature detection; delegates allocation to the helper; records path-to-address mapping in `.raw/.manifest.json` `address_map` for re-ingest stability.
- `skills/wiki-lint/SKILL.md` → Address Validation section: format check, uniqueness check, counter-drift check, address-map consistency check.
**Lint severity model** (matches `skills/wiki-lint/SKILL.md` Address Validation behavior):
- Post-rollout pages (frontmatter `created:` >= 2026-04-23, or any page newly created after DragonScale adoption) that lack an address are **errors**. This is the silent-regression guard.
- Legacy pages (`created:` < 2026-04-23) without addresses are **informational**. The optional `.vault-meta/legacy-pages.txt` manifest can grandfather pages whose `created:` metadata is wrong or missing.
- Meta pages (`_index.md`, `index.md`, `log.md`, `hot.md`, etc.) and fold pages are excluded entirely.
---
## Mechanism 3 — Semantic Tiling Lint
The tiling property says the same concept should live in one canonical page. Enforce it with an embedding-based dedup check in `wiki-lint`.
**Procedure (calibrated, not a guess):**
1. Compute embeddings for every page. Default model: local `nomic-embed-text` via ollama on `http://127.0.0.1:11434`. Cost: local hardware time only (no API fees). The script supports a remote override under `--allow-remote-ollama`; remote endpoints may incur provider API fees.
2. Compute pairwise cosine similarities for all page pairs.
3. **Calibration** (one-time, before first use): label 50-100 in-vault page pairs as duplicate/near/distinct; find the thresholds that optimize target precision for each band.
4. **Default bands** (used before calibration, then refined):
- `≥ 0.90` — near-duplicate, lint error
- `0.80 – 0.90` — review bucket, lint warning
- `< 0.80` — distinct, no flag
5. Never auto-merge. Output a review list.
**Why not a fixed 0.85?** v0.1 used 0.85 with no justification. Published thresholds in the embeddings literature span a wide range (Sentence Transformers' `community_detection` defaults to 0.75; Quora-duplicate calibrations land around 0.77–0.83; sparse-model defaults differ again). Thresholds are model-, corpus-, and objective-dependent, so calibration is required.
---
## Mechanism 4 — Boundary-First Autoresearch
> **Status: shipped (Phase 4, opt-in)** as of 2026-04-24. Implementation: `scripts/boundary-score.py`. Integration: `skills/autoresearch/SKILL.md` Topic Selection section B. Tests: `tests/test_boundary_score.py`.
Boundary pages (high out-degree relative to in-degree, recency-weighted) are the vault's frontier. `/autoresearch` invoked without a topic reads the top-5 boundary pages and offers them as research candidates; the user selects one (or types a free-text topic, or declines all and falls back to the original ask-user mode).
**Formula (exact)**:
```
out_degree(p) = count of distinct filename-stem wikilinks in body of p that resolve to scoreable pages
in_degree(p) = count of distinct scoreable pages whose body contains a wikilink to p
recency_weight(p) = exp(-days_since_updated / 30) # no floor; old pages approach 0
boundary_score(p) = (out_degree - in_degree) * recency_weight
```
**Link resolution**: filename-stem only. `[[Foo]]` resolves to `Foo.md` anywhere in the vault. Aliases declared via frontmatter `aliases:` are NOT parsed. Folder-qualified links (e.g. `[[notes/Foo]]`) are resolved by stem alone. This matches Obsidian's default behavior for unique filenames but does not implement full alias resolution.
**Scoreable** = any page NOT excluded by any of:
- frontmatter `type: meta` or `type: fold`
- filename in `{_index.md, index.md, log.md, hot.md, overview.md, dashboard.md, Wiki Map.md, getting-started.md}`
- path prefix in `wiki/folds/` or `wiki/meta/`
- symlinks or paths whose resolved target escapes the vault root (rejected at scan time)
**Code-block filtering**: triple-backtick AND triple-tilde fenced code blocks are skipped, with CommonMark-like length tracking so a longer opening fence is not closed by a shorter inner fence. Indented code blocks (4+ spaces) are NOT filtered because Obsidian bullet lists commonly use 4-space indentation and contain real wikilinks. See `scripts/boundary-score.py:RECENCY_HALFLIFE_DAYS` for the sole tunable constant.
**Honest labeling**: this mechanism is **agenda control**, not pure memory. It shapes what the agent researches next. It is included in DragonScale because it is a direct consequence of the dragon-curve boundary analogy, and because it pairs naturally with folds (freshly folded pages have low out-degree; frontier pages are pre-fold). But the "memory only, not reasoning" framing does not cover it. Users who want a strict memory-layer subset should omit this mechanism (simply do not invoke `/autoresearch` without a topic, or do not set up `scripts/boundary-score.py`).
**What is NOT included**:
- No auto-triggering. `/autoresearch` is still user-invoked.
- No persistent boundary-score cache. Scoring is O(N * avg_links) and runs on every invocation from fresh wiki/ state.
- No integration with folds or addresses. Pure graph analysis on the wikilink graph.
- No automatic topic selection without user confirmation. The helper presents choices; the user picks.
---
## Operational Policies (required before implementation)
Adversarial review flagged these gaps in v0.1. Each must be decided before the corresponding phase ships.
| Policy | Phase 0 position | Decision point |
|---|---|---|
| **Retention / GC** | No automatic deletion. Pages are permanent. | Revisit if vault exceeds ~5000 pages. |
| **Tombstones** | None. Deleted pages are removed via git revert. | Revisit if delete events become common. |
| **Versioning** | Relied on git history, not in-vault versioning. | Address-hash rotation policy doubles as a coarse version signal. |
| **Conflict resolution for contradictory folds** | Meta-page must quote both sources with explicit "conflict" callout. No automatic resolution. | Phase 1 spec required. |
| **Concurrency / atomicity** | Single-writer assumption (one Claude session at a time). PostToolUse auto-commit serializes. | Multi-writer case deferred. |
| **Provenance for meta-pages** | Every fold page must include frontmatter listing children and fold level. | Phase 1 must enforce. |
| **Access control** | Out of scope. This is a single-user vault. | Revisit only if shared. |
---
## Mapping to Claude-Obsidian
| Mechanism | Status | New | Extends |
|---|---|---|---|
| Fold operator | shipped (Phase 1, dry-run verified) | `skills/wiki-fold/` | reads `log.md`, writes `wiki/folds/`, updates `index.md` on commit |
| Address anchors | shipped (Phase 2, opt-in) | `scripts/allocate-address.sh`, new frontmatter field | `wiki-ingest` (assignment), `wiki-lint` (validation) |
| Semantic tiling | shipped (Phase 2/3, opt-in) | `scripts/tiling-check.py`, `.vault-meta/tiling-thresholds.json` | `wiki-lint` with banded thresholds, calibration procedure documented |
| Boundary-first | shipped (Phase 4, opt-in) | `scripts/boundary-score.py`, `tests/test_boundary_score.py` | `skills/autoresearch/SKILL.md` Topic Selection section B; `commands/autoresearch.md` no-topic path |
The existing hot → index → domain → page hierarchy already implements self-similarity across scales. That's the one dragon-curve property this vault had before DragonScale.
---
## Why This Over Alternatives
| Pattern | What it gives | What DragonScale adds |
|---|---|---|
| MemGPT virtual context (two-tier paging) | Main context ↔ external context swap | More than two levels; explicit fold triggers; dedup lint |
| Pure LSM compaction | Exponential write-path throughput | Semantic-layer mechanisms (tiling, boundary); additive rollups over destructive merges |
| Ad-hoc `/save` | Human-triggered filing | Rule-based fold cadence |
| Vector-only RAG | Retrieval | Canonical-home structure; lineage addresses |
DragonScale composes patterns validated in adjacent systems: LSM *batching* (databases), MemGPT *paging* (agents), Anthropic *cache ordering* (prompt engineering), and embedding *dedup* (knowledge graphs).
---
## Known Limitations (v0.3)
- **Unvalidated at scale.** All four mechanisms are theoretical; none tested on a multi-thousand-page vault.
- **Fold cadence is a knob, not a theorem.** `k=4` is a starting guess. Adaptive triggers are likely better.
- **Address stability is unsolved.** Hash rotation on edits is a known issue; deferred.
- **Boundary-first crosses scope.** Included with a warning, not quietly.
- **Calibration load.** Tiling requires a one-time labeling pass; without it, only defaults apply.
---
## Primary Sources
Verified against primary sources on 2026-04-23. **Scope of tagging**: the specific numeric values, formulas, and named patterns below are tagged **[sourced]** when directly citable, **[derived]** when derivable from sourced material, or **[conjecture]** when based on reasoning without a specific source. **Not tagged** (and readers should treat as interpretive synthesis): framing sentences in the body such as "composes patterns validated," "self-similarity already exists," and the design rationale tying the four mechanisms together. These are editorial, not source-backed.
**Dragon curve math [sourced]**
- Boundary dimension `2·log₂(λ)` where `λ³ − λ² − 2 = 0`, giving 1.523627086: [Dragon curve, Wikipedia](https://en.wikipedia.org/wiki/Dragon_curve)
- Paper-folding construction and OEIS A014577: [Regular paperfolding sequence, Wikipedia](https://en.wikipedia.org/wiki/Regular_paperfolding_sequence); [OEIS A014577](https://oeis.org/A014577)
- Tiling and rep-tiles: [Wolfram Demonstrations: Tiling Dragons and Rep-tiles of Order Two](https://demonstrations.wolfram.com/TilingDragonsAndRepTilesOfOrderTwo/)
**LSM trees [sourced]**
- Level size ratios and compaction semantics: [RocksDB Compaction wiki](https://github.com/facebook/rocksdb/wiki/Compaction), [RocksDB Tuning Guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide), [How to Grow an LSM-tree? (2025)](https://arxiv.org/abs/2504.17178)
- LevelDB 10× level ratio: referenced in the arXiv paper above. Treat as *typical*, not required.
**LLM memory architectures [sourced]**
- OS-inspired paging: [MemGPT: Towards LLMs as Operating Systems (Packer et al. 2023)](https://arxiv.org/abs/2310.08560)
- Position sensitivity: [Lost in the Middle (Liu et al. 2023)](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long)
- Note-based agentic memory: [A-Mem (2025)](https://arxiv.org/abs/2502.12110)
**Prompt caching [sourced]**
- Byte-identical prefix requirement, breakpoint mechanics, TTL options: [Anthropic Prompt Caching docs](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
**Embedding thresholds [sourced]**
- Sentence Transformers defaults and calibration examples: [Sentence Transformers util](https://sbert.net/docs/package_reference/util.html), [SBERT evaluation docs](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html)
**Reasoning search (out of scope, cited only to justify the scope boundary) [sourced]**
- [Tree of Thoughts (Yao et al. 2023)](https://arxiv.org/abs/2305.10601)
**Items marked [conjecture] in this doc:**
- `k=4`/`k=5` starting value for fold cadence (needs empirical tuning)
- `~30s` full-vault embedding-pass time (needs measurement)
- `boundary_score` formula exact weighting (a plausible starting form; not validated against retrieval metrics)
**Items marked [derived]:**
- `⌈log₂(N)⌉` fold-depth bound (trivially derivable from the entry-count trigger)
- Default tiling bands `{≥0.90, 0.80-0.90, <0.80}` before calibration (interpolated from cited ranges in Sentence Transformers examples; not optimal by construction)
---
## Review History
**v0.1 (2026-04-23, initial draft)** — written after a verification pass against Wikipedia, arXiv, and Anthropic docs. Four mechanisms proposed.
**v0.4 (2026-04-24, Phase 4 shipped)** — Mechanism 4 (boundary-first autoresearch) implemented as `scripts/boundary-score.py` with `tests/test_boundary_score.py` covering parsing, recency weight, wikilink extraction (with fence-length + tilde + indented-block tests), graph construction (self-loop/unresolved/meta-target exclusion), symlink rejection, and CLI surface (`--top`, `--page`, `--json`). Integrated into `skills/autoresearch/SKILL.md` as an opt-in Topic Selection mode with explicit helper-failure fallback. Spec's "NOT IMPLEMENTED" marker removed; exact scoring formula (no recency floor), filename-stem-only resolution disclosure, scope, and "what is NOT included" section added. Phase 3.6 pre-Phase-4 hardening shipped concurrently (5 fixes: `--report` path confinement, rollout baseline, AGENTS.md consistency, wiki-ingest .raw contradiction, install-guide version).
**v0.3 (2026-04-23, Phase 2 alignment)** — Mechanism 2 rewritten to match the actual Phase 2 MVP shipped in `wiki-ingest` and `wiki-lint`. Renamed from "Content-Addressable Paths" to "Deterministic Page Addresses" (the MVP is a creation-order counter, not a content hash). Documented the extension path for fold-ancestry bits and content-hash suffix, both explicitly deferred.
**v0.2 (2026-04-23, post-adversarial review)** — after `codex exec` adversarial review. All 7 critiques accepted:
1. *LSM "structurally identical"* → weakened to "loosely analogous to hierarchical rollup"; non-inherited properties listed explicitly.
2. *Prompt cache address benefit* → removed strong claim; narrowed to organizational convention.
3. *0.85 threshold* → replaced with calibration procedure and banded defaults.
4. *2^k cadence* → justified as implementation convenience; adaptive trigger flagged as preferred for production.
5. *Scope boundary contradiction* → acknowledged; boundary-first explicitly labeled as agenda control.
6. *Missing production mechanisms* → added Operational Policies section (retention, versioning, conflict resolution, concurrency, provenance).
7. *Unverified claims* → tagged specific numeric values, formulas, and named patterns as [sourced], [derived], or [conjecture]. Editorial synthesis in the body explicitly flagged as not tagged (see scope note under Primary Sources).
---
## Connections
See [[LLM Wiki Pattern]] for the broader pattern this extends.
See [[Compounding Knowledge]] for why persistent state is the precondition for DragonScale.
See [[Hot Cache]] for the existing 500-word session context, which is a level-0 manual fold.
See [[Andrej Karpathy]] for the intellectual lineage.
wiki/concepts/Dynamic Buckling Analysis.md
+50
View File
@@ -0,0 +1,50 @@
---
type: concept
title: "Dynamic Buckling Analysis"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000037
aliases:
- dynamic buckling
- parametric resonance buckling
- 동적 좌굴
- 매개 변수 공진
tags:
- concept
- finite-element-method
- dynamic-buckling
- shell-elements
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Dynamic Instability Region]]"
- "[[Geometric Stiffness Matrix]]"
- "[[MITC4 Shell Element]]"
- "[[Direct Time Integration Methods]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Dynamic Buckling Analysis
## Definition
Dynamic buckling analysis evaluates instability that occurs when a structure is subjected to time-varying compressive loading, often expressed as a parametric resonance problem.
## How It Works
The thesis frames the dynamic load as an axial compressive load with static and harmonic components. The finite element model supplies stiffness, geometric stiffness, and mass matrices. Vibration and buckling eigenvalue analyses are then used to determine natural frequencies, critical buckling loads, and the excitation/load combinations that form instability boundaries.
## Why It Matters
Thin shell structures can be vulnerable to buckling and vibration. For vehicles exposed to large dynamic axial loads, such as high-speed aircraft, missiles, launch vehicles, re-entry vehicles, or supercavitating underwater vehicles, static buckling checks alone can miss instability regions caused by dynamic loading.
## Validation Thread
The source validates dynamic buckling against beam theory, then compares plate and stiffened plate instability regions with experimental trends. The beam example reports a natural frequency of 10.7 Hz and a critical buckling load of 71.73 N, while the plate example reports a natural frequency of 5.17 Hz and a critical buckling load of 49.6 N.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Dynamic Instability Region.md
+47
View File
@@ -0,0 +1,47 @@
---
type: concept
title: "Dynamic Instability Region"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000038
aliases:
- instability region
- dynamic buckling boundary
- 불안정 경계 영역
tags:
- concept
- finite-element-method
- dynamic-buckling
- stability
status: current
related:
- "[[Dynamic Buckling Analysis]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Finite Element Eigenproblem Solvers]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Dynamic Instability Region
## Definition
A dynamic instability region is the region in loading and excitation-frequency space where a dynamically compressed structure becomes unstable.
## How It Works
In the thesis, the instability region is obtained by sweeping dynamic load and excitation frequency parameters in a finite element dynamic buckling formulation. For the beam example, when the static load component is zero, the instability frequency at zero dynamic load appears near twice the natural frequency. As dynamic load amplitude increases, the instability region widens.
## Why It Matters
The instability region is a design-level output: it identifies combinations of load amplitude and excitation frequency that should be avoided or mitigated by changing stiffness, mass, damping, supports, or reinforcement layout.
## Source Comparisons
The plate and stiffened plate examples compare finite element instability regions with experimental trends. The stiffened plate comparison shows larger discrepancies than the flat plate, attributed in the source to structural imperfections introduced by real manufacturing and reinforcement.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Engineering Mathematical Models.md
+45
View File
@@ -0,0 +1,45 @@
---
type: concept
title: "Engineering Mathematical Models"
complexity: intermediate
domain: computational-mechanics
aliases:
- engineering model idealization
- mathematical modeling
created: 2026-05-28
updated: 2026-05-28
address: c-000007
tags:
- concept
- modeling
- finite-element-method
status: current
related:
- "[[Finite Element Method]]"
- "[[Computational Mechanics]]"
sources:
- "[[Finite Element Procedures]]"
---
# Engineering Mathematical Models
## Definition
Engineering mathematical models are idealized descriptions of physical systems, including geometry, material behavior, loads, boundary conditions, constraints, and the governing equations selected for analysis.
## How It Works
The analyst chooses a model that is simple enough to solve and rich enough to answer the engineering question. A finite element solution then approximates that selected model. If the model is poorly chosen, a numerically accurate result can still be physically misleading.
## Why It Matters
The source positions finite element analysis as part of an iterative engineering process: define the model, solve it, assess the result, compare against expected physical behavior, and refine the model when needed.
## Connections
- [[Finite Element Method]] solves mathematical models after discretization.
- [[Mixed Finite Element Formulations]] and [[Nonlinear Finite Element Analysis]] are needed when the chosen model includes constraints, incompressibility, contact, or nonlinear material response.
## Sources
- [[Finite Element Procedures]]
wiki/concepts/Finite Element Eigenproblem Solvers.md
+55
View File
@@ -0,0 +1,55 @@
---
type: concept
title: "Finite Element Eigenproblem Solvers"
complexity: advanced
domain: computational-mechanics
aliases:
- eigensystem solution
- finite element eigenvalue analysis
- modal analysis
created: 2026-05-28
updated: 2026-05-28
address: c-000015
tags:
- concept
- finite-element-method
- eigenproblems
status: current
related:
- "[[Finite Element Method]]"
- "[[Direct Time Integration Methods]]"
- "[[Static Equilibrium Equation Solvers]]"
- "[[Dynamic Buckling Analysis]]"
- "[[Geometric Stiffness Matrix]]"
- "[[BLZPACK]]"
sources:
- "[[Finite Element Procedures]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Finite Element Eigenproblem Solvers
## Definition
Finite element eigenproblem solvers compute eigenvalues and eigenvectors of matrix systems such as `K phi = lambda M phi`, commonly used for free vibration, buckling, modal reduction, and stability analysis.
## How It Works
The source introduces eigenvector properties, shifting, zero-mass effects, standard-form transformations, Rayleigh-Ritz approximations, component mode synthesis, error bounds, and solution methods including inverse iteration, forward iteration, Rayleigh quotient iteration, Jacobi transformations, Householder-QR, polynomial iteration, Sturm sequence techniques, Lanczos iteration, and subspace iteration.
The dynamic buckling thesis adds an implementation example: [[BLZPACK]], based on Block Lanczos, is used for vibration and buckling eigenvalue analyses in a shell dynamic buckling program.
## Why It Matters
Large finite element models can have many degrees of freedom, but engineering decisions often require only selected modes or eigenvalues. Solver choice determines whether the analysis can efficiently find the physically relevant part of the spectrum.
## Connections
- [[Direct Time Integration Methods]] can be contrasted with mode superposition.
- [[Static Equilibrium Equation Solvers]] shares matrix factorization and conditioning concerns.
- [[Finite Element Program Implementation]] must support sparse matrix operations and vector iteration workflows.
## Sources
- [[Finite Element Procedures]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Finite Element Heat Transfer and Field Problems.md
+47
View File
@@ -0,0 +1,47 @@
---
type: concept
title: "Finite Element Heat Transfer and Field Problems"
complexity: intermediate
domain: computational-mechanics
aliases:
- finite element field problems
- finite element heat transfer
created: 2026-05-28
updated: 2026-05-28
address: c-000012
tags:
- concept
- finite-element-method
- heat-transfer
- fluid-flow
status: current
related:
- "[[Finite Element Method]]"
- "[[Direct Time Integration Methods]]"
sources:
- "[[Finite Element Procedures]]"
---
# Finite Element Heat Transfer and Field Problems
## Definition
Finite element heat transfer and field problems apply the finite element workflow to scalar or vector fields beyond structural displacement, including temperature, seepage, inviscid flow, torsion, acoustics, and viscous incompressible flow.
## How It Works
The governing field equation and boundary conditions are written in a weak or weighted residual form, discretized over elements, assembled into a global system, and solved under steady-state, transient, linear, or nonlinear assumptions. The source treats heat transfer first, then general field problems, then viscous incompressible fluid flow and fluid-structure interaction.
## Why It Matters
The chapter shows that finite element procedures are not limited to solid mechanics. Similar discretization and assembly patterns can solve different physical laws when the governing equations and boundary terms are formulated correctly.
## Connections
- [[Engineering Mathematical Models]] determines which governing equation is appropriate.
- [[Direct Time Integration Methods]] applies to transient heat transfer and flow problems.
- [[Mixed Finite Element Formulations]] is relevant for incompressible flow and pressure-like fields.
## Sources
- [[Finite Element Procedures]]
wiki/concepts/Finite Element Method.md
+65
View File
@@ -0,0 +1,65 @@
---
type: concept
title: "Finite Element Method"
complexity: intermediate
domain: computational-mechanics
aliases:
- FEM
- finite element analysis
created: 2026-05-28
updated: 2026-05-28
address: c-000006
tags:
- concept
- finite-element-method
status: current
related:
- "[[Computational Mechanics]]"
- "[[Engineering Mathematical Models]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Isoparametric Finite Elements]]"
- "[[Solid Element Notes]]"
- "[[Isoparametric Linear Solid Elements]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
---
# Finite Element Method
## Definition
The finite element method is a numerical procedure for approximating solutions to physical problems by replacing a continuous domain with connected finite elements, choosing interpolation functions over each element, assembling local equations into a global algebraic system, and solving for the unknown field variables.
## How It Works
The workflow starts with a physical problem and an idealized mathematical model. The domain is discretized into elements, field variables are approximated using nodal degrees of freedom, element equations are derived from differential, variational, virtual work, or weighted residual statements, and the assembled global system is solved after boundary conditions and constraints are applied.
## Why It Matters
Finite element analysis lets engineers approximate complex geometries, material behavior, loads, and boundary conditions that are difficult to solve analytically. The source repeatedly emphasizes that solution quality depends as much on modeling choices as on numerical algorithms.
The shell element paper adds a focused example: a useful element is not only a mesh topology, but a formulation choice that controls locking, rigid-body behavior, nonlinear kinematics, and benchmark performance.
The shell FE review reinforces the same modeling-first point: shell results require simultaneous understanding of physical behavior, the selected shell mathematical model, and the finite element approximation.
[[Solid Element Notes]] adds a compact element-level derivation for 3D continuum elements: natural-coordinate shape functions, Jacobian derivative mapping, `B` and `D` matrices, stiffness integration, and incompatible mode enrichment.
## Key Connections
- [[Engineering Mathematical Models]] defines what is being solved.
- [[Displacement-Based Finite Element Formulation]] gives the main solid mechanics derivation.
- [[Isoparametric Finite Elements]] describes practical element construction.
- [[Continuum Mechanics Based Four-Node Shell Element]] is a focused low-order shell formulation example.
- [[Static Equilibrium Equation Solvers]], [[Direct Time Integration Methods]], and [[Finite Element Eigenproblem Solvers]] solve the resulting systems.
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
- [[Solid Element Notes]]
wiki/concepts/Finite Element Program Implementation.md
+64
View File
@@ -0,0 +1,64 @@
---
type: concept
title: "Finite Element Program Implementation"
complexity: advanced
domain: computational-mechanics
aliases:
- finite element code architecture
- STAP
created: 2026-05-28
updated: 2026-05-28
address: c-000016
tags:
- concept
- finite-element-method
- implementation
status: current
related:
- "[[Finite Element Method]]"
- "[[Isoparametric Finite Elements]]"
- "[[Static Equilibrium Equation Solvers]]"
- "[[OOFEM]]"
- "[[MITC4 Shell Element]]"
- "[[Dynamic Buckling Analysis]]"
- "[[BLZPACK]]"
- "[[ABAQUS]]"
sources:
- "[[Finite Element Procedures]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Finite Element Program Implementation
## Definition
Finite element program implementation is the software organization needed to read model data, compute element quantities, assemble global matrices, solve equations, recover stresses, and report results.
## How It Works
The source describes the implementation path through nodal and element input, element stiffness, mass, and equivalent nodal load calculation, matrix assembly, stress calculation, and an example program called STAP. The flow is element-local first, global-system second: each element contributes local matrices and vectors, which are mapped into global degrees of freedom and assembled.
The MITC4 source adds a concrete code-level example: a shell element formulation is implemented in [[OOFEM]], verified through patch tests, and then checked on the [[Scordelis-Lo Shell Benchmark]].
The dynamic buckling thesis adds a second program implementation pattern: a custom MITC4 shell code uses a lumped mass matrix and [[BLZPACK]] for eigenvalue problems, then validates results against theoretical solutions, experiments, and [[ABAQUS]] comparisons.
## Why It Matters
The finite element method becomes useful only when the mathematical formulation is encoded into reliable data structures and algorithms. Implementation details determine whether element routines, sparse matrix storage, solver selection, boundary condition handling, and postprocessing remain consistent.
## Implementation Checklist
- Define node, element, material, load, and boundary condition input structures.
- Map local element degrees of freedom to global equation numbers.
- Compute element matrices using shape functions, Jacobians, constitutive laws, and quadrature.
- Assemble global sparse matrices and vectors.
- Apply constraints and solve the resulting system.
- Recover stresses or other derived quantities from the solved nodal field.
- Verify new element implementations with patch tests and benchmark problems before treating production results as reliable.
## Sources
- [[Finite Element Procedures]]
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Geometric Stiffness Matrix.md
+51
View File
@@ -0,0 +1,51 @@
---
type: concept
title: "Geometric Stiffness Matrix"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000039
aliases:
- initial stress stiffness matrix
- stress stiffness matrix
- 기하 강성 행렬
tags:
- concept
- finite-element-method
- nonlinear-analysis
- buckling
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Dynamic Buckling Analysis]]"
- "[[Green-Lagrange Strain Linearization]]"
- "[[Total Lagrangian Shell Formulation]]"
- "[[Finite Element Eigenproblem Solvers]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Geometric Stiffness Matrix
## Definition
The geometric stiffness matrix is a stiffness contribution that arises from the current stress state and geometry of a structure, and is essential in buckling and geometric nonlinear analysis.
## How It Works
In the dynamic buckling thesis, the geometric stiffness matrix is derived through a [[Total Lagrangian Shell Formulation]] for the [[MITC4 Shell Element]]. The nonlinear strain terms are separated so that material stiffness and initial-stress stiffness contributions can be assembled. Static buckling then appears as an eigenvalue problem involving structural stiffness and geometric stiffness, while dynamic buckling also involves mass and time-varying load parameters.
## Why It Matters
Without geometric stiffness, a finite element model may predict ordinary elastic response but cannot capture the loss of stability associated with compressive pre-stress. It is the bridge from stress state to buckling load, mode shape, and dynamic instability boundary.
## Connections
- [[Green-Lagrange Strain Linearization]] explains how nonlinear strain terms feed tangent construction.
- [[Finite Element Eigenproblem Solvers]] are needed once stiffness and geometric stiffness form a buckling eigenproblem.
- [[Dynamic Buckling Analysis]] uses separate geometric stiffness terms for static and dynamic load components.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Green-Lagrange Strain Linearization.md
+50
View File
@@ -0,0 +1,50 @@
---
type: concept
title: "Green-Lagrange Strain Linearization"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000030
aliases:
- Green Lagrange strain expansion
- nonlinear strain linearization
- total Lagrangian tangent strain terms
tags:
- concept
- finite-element-method
- nonlinear-analysis
- shell-elements
status: current
related:
- "[[MITC Study Notes]]"
- "[[Total Lagrangian Shell Formulation]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[MITC Shell Kinematics]]"
sources:
- "[[MITC Study Notes]]"
---
# Green-Lagrange Strain Linearization
## Definition
Green-Lagrange strain linearization separates the nonlinear strain measure into terms that can be used to form residual forces and tangent stiffness contributions during incremental nonlinear finite element analysis.
## How It Works
The study notes use Green-Lagrange strain with second Piola-Kirchhoff stress in a reference-configuration virtual work statement. The strain expression is expanded with respect to the current displacement state and an incremental displacement. This separates terms associated with the existing strain state, terms linear in the increment, and terms nonlinear in the increment. The variation of the strain then produces internal force and tangent terms for Newton-Raphson iteration.
## Why It Matters
In nonlinear shell analysis, the element stiffness is not a fixed matrix. The tangent must account for both material response and geometry-dependent stress terms. Linearizing the Green-Lagrange strain is the step that turns the nonlinear virtual work equation into a solvable incremental system.
## Connections
- [[Total Lagrangian Shell Formulation]] provides the reference configuration and stress/strain pair.
- [[MITC Shell Kinematics]] defines the displacement and director variables being linearized.
- [[Nonlinear Finite Element Analysis]] supplies the Newton iteration context.
## Sources
- [[MITC Study Notes]]
wiki/concepts/Hot Cache.md
-95
View File
@@ -1,95 +0,0 @@
---
type: concept
title: "Hot Cache"
complexity: basic
domain: knowledge-management
aliases:
- "hot.md"
- "Session Cache"
- "Context Cache"
created: 2026-04-07
updated: 2026-04-07
tags:
- concept
- knowledge-management
- context
status: mature
related:
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[index]]"
- "[[hot]]"
- "[[concepts/_index]]"
sources:
---
# Hot Cache
A ~500-word summary of the most recent context in the wiki vault. Stored in `wiki/hot.md`. Updated at the end of every session and after every significant ingest or query.
The hot cache exists to answer one question: "where did we leave off?" A new session reads `hot.md` first. If the answer is there, it skips crawling the rest of the wiki.
---
## What It Stores
- What was most recently ingested or discussed
- Key recent facts and takeaways
- Pages recently created or updated
- Active threads and open questions
- What the user is currently focused on
---
## Format
```markdown
---
type: meta
title: "Hot Cache"
updated: YYYY-MM-DDTHH:MM:SS
---
# Recent Context
## Last Updated
YYYY-MM-DD — [what happened]
## Key Recent Facts
- [Most important recent takeaway]
- [Second]
## Recent Changes
- Created: new wiki pages from this ingest
- Updated: existing pages with new connections
- Flagged: contradictions between sources where found
## Active Threads
- User is researching [topic]
- Open question: [thing being investigated]
```
---
## Rules
- Keep it under 500 words. It is a cache, not a journal.
- Overwrite it completely each time. Not append-only.
- One file. Not split by date.
- Updated after every ingest, significant query, and at the end of each session.
---
## Why It Matters
Without the hot cache, every session starts cold: read the index (1000 tokens), read several domain sub-indexes, read several individual pages. With the hot cache, the first 500 tokens often have everything needed.
In practice, adding `hot.md` to an executive assistant vault dramatically reduces the token cost of session startup compared to crawling multiple wiki pages.
The hot cache is especially valuable in cross-project setups: another Claude Code project can point at this vault and read `hot.md` first to get recent context at minimal token cost.
---
## Connections
The hot cache is part of the [[LLM Wiki Pattern]] token discipline strategy. See [[index]] for how the broader navigation works.
wiki/concepts/Incompatible Mode Solid Elements.md
+57
View File
@@ -0,0 +1,57 @@
---
type: concept
title: "Incompatible Mode Solid Elements"
complexity: advanced
domain: computational-mechanics
aliases:
- incompatible mode solid element
- nonconforming solid element mode
- internal mode solid element
- static condensation of incompatible modes
created: 2026-05-28
updated: 2026-05-28
address: c-000053
tags:
- concept
- finite-element-method
- solid-elements
- locking
status: current
related:
- "[[Solid Element Notes]]"
- "[[Mixed Finite Element Formulations]]"
- "[[Solid Element Stiffness Integration]]"
- "[[Shell Locking Phenomenon]]"
sources:
- "[[Solid Element Notes]]"
---
# Incompatible Mode Solid Elements
## Definition
Incompatible mode solid elements add internal, non-nodal displacement modes to a solid element to enrich its deformation field and reduce locking or overly stiff behavior.
## How It Works
The source introduces extra internal degrees of freedom for selected 6-node wedge and 8-node hexahedral elements. The standard displacement interpolation is augmented by additional mode functions, producing an expanded strain-displacement matrix:
```text
B_tot = [ B B_inc ]
```
The resulting stiffness is assembled from the expanded matrix. Because the incompatible mode degrees of freedom are internal to the element and are not global nodal unknowns, they are eliminated by static condensation before the global solve.
## Why It Matters
Low-order displacement-based solid elements can be too stiff in deformation states their interpolation cannot represent well. Incompatible modes are a local enrichment strategy: they improve element flexibility without changing the global mesh topology or adding nodal unknowns.
## Connections
- [[Solid Element Stiffness Integration]] is modified because the `B` matrix is augmented before condensation.
- [[Mixed Finite Element Formulations]] provides the broader reliability pattern of adding or altering fields to avoid locking and constraints.
- [[Shell Locking Phenomenon]] is a shell-specific locking case; this page records the analogous solid-element enrichment strategy from the source.
## Sources
- [[Solid Element Notes]]
wiki/concepts/Isoparametric Finite Elements.md
+61
View File
@@ -0,0 +1,61 @@
---
type: concept
title: "Isoparametric Finite Elements"
complexity: advanced
domain: computational-mechanics
aliases:
- isoparametric elements
- isoparametric formulation
created: 2026-05-28
updated: 2026-05-28
address: c-000009
tags:
- concept
- finite-element-method
- numerical-integration
status: current
related:
- "[[Finite Element Method]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Mixed Finite Element Formulations]]"
- "[[Solid Element Notes]]"
- "[[Isoparametric Linear Solid Elements]]"
- "[[Solid Element Shape Functions]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Solid Element Notes]]"
---
# Isoparametric Finite Elements
## Definition
Isoparametric finite elements use the same interpolation framework to represent both element geometry and field variables, mapping a simple natural-coordinate element to the physical element through shape functions and a Jacobian.
## How It Works
The element is defined in natural coordinates, shape functions interpolate geometry and unknown fields, the Jacobian maps derivatives and integration measures into physical coordinates, and numerical quadrature evaluates stiffness, mass, load, and other element matrices.
## Why It Matters
The isoparametric framework is the practical bridge from finite element theory to general-purpose element routines. It supports quadrilateral, triangular, solid, beam, plate, and shell elements, while exposing key numerical choices such as quadrature order, reduced integration, selective integration, and element distortion sensitivity.
The four-node shell paper is an example of this bridge: a general quadrilateral shell can be economical and nonlinear-capable, but the interpolation must be modified to avoid shear locking in thin shell limits.
[[Solid Element Notes]] provides the direct 3D continuum example: 4-node tetrahedral, 5-node pyramid, 6-node wedge, and 8-node hexahedral elements interpolate both position and displacement with the same natural-coordinate functions before mapping derivatives through the Jacobian.
## Failure Modes
- Distorted elements can degrade accuracy or convergence.
- Under-integration can introduce spurious mechanisms.
- Overly constrained interpolation can cause locking.
- Incompressible behavior often requires mixed displacement/pressure treatment.
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[Solid Element Notes]]
wiki/concepts/Isoparametric Linear Solid Elements.md
+64
View File
@@ -0,0 +1,64 @@
---
type: concept
title: "Isoparametric Linear Solid Elements"
complexity: intermediate
domain: computational-mechanics
aliases:
- linear solid elements
- first-order solid elements
- isoparametric solid elements
- 3D solid elements
created: 2026-05-28
updated: 2026-05-28
address: c-000049
tags:
- concept
- finite-element-method
- solid-elements
- isoparametric-elements
status: current
related:
- "[[Solid Element Notes]]"
- "[[Isoparametric Finite Elements]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Solid Element Shape Functions]]"
- "[[Solid Element Strain-Displacement Matrix]]"
- "[[Solid Element Stiffness Integration]]"
sources:
- "[[Solid Element Notes]]"
---
# Isoparametric Linear Solid Elements
## Definition
Isoparametric linear solid elements are first-order three-dimensional continuum finite elements that interpolate both geometry and displacement with the same nodal shape functions.
## How They Work
The source treats solid elements as volume elements with three translational displacement degrees of freedom per node: `u`, `v`, and `w`. They do not include rotational degrees of freedom, so connecting them directly to beam, plate, or shell elements can require care to avoid singular constraints.
The physical position and displacement field are both interpolated from nodal values:
```text
x(xi) = sum N_i(xi) x_i
u(xi) = sum N_i(xi) u_i
```
The covered topologies are 4-node tetrahedron, 5-node pyramid, 6-node wedge, and 8-node hexahedron. In each case, the element is defined in natural coordinates and mapped to physical space through the Jacobian.
## Practical Notes
- Solid elements are suited to three-dimensional volume response rather than beam or shell idealizations.
- Aspect ratios close to one are preferred because distortion degrades the shape-function mapping and numerical integration quality.
- The absence of rotational degrees of freedom is a modeling interface issue when solid elements meet structural elements.
## Connections
- [[Solid Element Shape Functions]] defines the natural-coordinate interpolation for each covered topology.
- [[Solid Element Strain-Displacement Matrix]] converts the displacement interpolation into engineering strain components.
- [[Solid Element Stiffness Integration]] assembles the stiffness matrix from `B`, `D`, and the Jacobian.
## Sources
- [[Solid Element Notes]]
wiki/concepts/LLM Wiki Pattern.md
-97
View File
@@ -1,97 +0,0 @@
---
type: concept
title: "LLM Wiki Pattern"
complexity: intermediate
domain: knowledge-management
aliases:
- "LLM Knowledge Base"
- "Karpathy Wiki"
- "Persistent Wiki"
created: 2026-04-07
updated: 2026-04-07
tags:
- concept
- knowledge-management
- llm
- obsidian
status: mature
related:
- "[[Hot Cache]]"
- "[[Compounding Knowledge]]"
- "[[Andrej Karpathy]]"
- "[[index]]"
- "[[concepts/_index]]"
sources:
---
# LLM Wiki Pattern
A pattern for building persistent, compounding knowledge bases using LLMs. Originated by [[Andrej Karpathy]]. The key insight: instead of re-deriving knowledge from raw documents on every query (RAG), the LLM incrementally builds and maintains a structured wiki that gets richer with every source added.
---
## The Core Idea
Most AI knowledge tools work like RAG: index raw documents, retrieve chunks at query time, generate an answer. Nothing accumulates. Ask a question that needs five documents and the LLM reassembles fragments every time.
The wiki pattern is different. When a new source arrives, the LLM reads it, extracts what matters, and integrates it into the wiki: updating entity pages, noting contradictions, strengthening the synthesis. The cross-references are already there. The knowledge is compiled once and kept current.
**The wiki is a persistent, compounding artifact.** The human curates sources and asks questions. The LLM writes and maintains everything.
---
## Three Layers
```
.raw/ Layer 1 — immutable source documents
wiki/ Layer 2 — LLM-generated knowledge base
CLAUDE.md Layer 3 — schema that tells the LLM how to maintain it
```
The LLM owns Layer 2 entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. The human reads; the LLM writes.
---
## Operations
**Ingest** — drop a source into `.raw/`, tell the LLM to process it. The LLM reads the source, discusses key takeaways, writes a summary page, updates entity and concept pages, and logs the operation. One source typically touches 8-15 wiki pages.
**Query** — ask a question. The LLM reads the index to find relevant pages, synthesizes an answer with citations. Good answers get filed back into the wiki.
**Lint** — periodic health check. Find orphan pages, dead links, stale claims, missing cross-references.
---
## Index and Log
**index.md** — content-oriented. A catalog of all pages with one-line summaries, organized by category. The LLM reads this first on every query to find relevant pages.
**log.md** — chronological. Append-only record of every ingest, query, and lint pass. Parseable: `grep "^## \[" log.md | head -10`
---
## Why It Works
The tedious part of maintaining a knowledge base is bookkeeping: updating cross-references, noting when new data contradicts old claims, keeping summaries current. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored. The wiki stays maintained because the cost of maintenance is near zero.
At small scale (~100 sources, ~hundreds of pages), the index file is sufficient. No vector database, no embeddings, no infrastructure. Just markdown files.
---
## Comparison to RAG
| Dimension | LLM Wiki | Semantic RAG |
|-----------|----------|-------------|
| Finding | Reads index, follows links | Similarity search over embeddings |
| Infrastructure | Just markdown files | Embedding model + vector DB |
| Cost | Tokens only | Ongoing compute + storage |
| Maintenance | Run a lint | Re-embed when content changes |
| Scale limit | Hundreds of pages | Millions of documents |
---
## Connections
See [[Compounding Knowledge]] for why the pattern produces more value over time.
See [[Hot Cache]] for the session context optimization.
See [[Andrej Karpathy]] for the pattern's origin.
wiki/concepts/MITC Shell Kinematics.md
+58
View File
@@ -0,0 +1,58 @@
---
type: concept
title: "MITC Shell Kinematics"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000029
aliases:
- MITC kinematics
- shell director kinematics
- degenerated continuum shell kinematics
tags:
- concept
- finite-element-method
- shell-elements
- mitc
status: current
related:
- "[[MITC Study Notes]]"
- "[[MITC4 Shell Element]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Total Lagrangian Shell Formulation]]"
sources:
- "[[MITC Study Notes]]"
---
# MITC Shell Kinematics
## Definition
MITC shell kinematics describe a shell element as a three-dimensional continuum degenerated through the shell thickness, with midsurface nodal positions and director vectors defining points inside the shell.
## How It Works
The study notes express reference and current shell positions using four-node shape functions plus a through-thickness coordinate multiplying nodal thickness and director vectors. The displacement field follows from the difference between current and reference positions. Incremental displacement is then split into nodal translation increments and director-vector increments caused by nodal rotations.
## Why It Matters
This kinematic setup is the bridge between solid-like continuum measures and shell element degrees of freedom. It lets the element use three-dimensional strain and stress measures while keeping the computational cost close to a low-order shell element.
## Practical Frame
- Midsurface interpolation locates the shell surface.
- Director vectors carry the through-thickness direction.
- Nodal translations move the midsurface.
- Nodal rotations update the directors.
- The through-thickness coordinate connects director motion to bending behavior.
## Connections
- [[MITC4 Shell Element]] uses this kinematic structure in a four-node quadrilateral element.
- [[Continuum Mechanics Based Four-Node Shell Element]] is the broader Dvorkin-Bathe lineage for this shell description.
- [[Total Lagrangian Shell Formulation]] supplies the reference-configuration viewpoint used later in the derivation.
## Sources
- [[MITC Study Notes]]
wiki/concepts/MITC4 Shell Element.md
+75
View File
@@ -0,0 +1,75 @@
---
type: concept
title: "MITC4 Shell Element"
complexity: advanced
domain: computational-mechanics
aliases:
- MITC4
- Mixed Interpolation of Tensorial Components shell element
- four-node quadrilateral MITC shell
created: 2026-05-28
updated: 2026-05-28
address: c-000023
tags:
- concept
- finite-element-method
- shell-elements
- mitc
- locking
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Shell Locking Phenomenon]]"
- "[[Uniform Optimal Convergence]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Dynamic Buckling Analysis]]"
- "[[MITC Study Notes]]"
- "[[MITC Shell Kinematics]]"
- "[[Green-Lagrange Strain Linearization]]"
- "[[Nonlinear Newmark-Beta Integration]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
- "[[Scordelis-Lo Shell Benchmark]]"
- "[[OOFEM]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# MITC4 Shell Element
## Definition
MITC4 is a four-node quadrilateral shell finite element that uses Mixed Interpolation of Tensorial Components to avoid transverse shear locking while retaining a low-order shell topology.
## How It Works
The element starts from a three-dimensional continuum description degenerated to shell behavior. Its displacement field uses four corner nodes, director vectors through the shell thickness, three translations, and two rotations at each node. Direct interpolation of this displacement field can create nonzero transverse shear strain under thin-shell bending, so MITC4 constructs assumed transverse shear strain components from edge-midpoint tying locations and transforms them through the convected coordinate basis.
The study notes expand the derivation path: [[MITC Shell Kinematics]] defines reference/current positions and director updates, [[Green-Lagrange Strain Linearization]] supplies the nonlinear tangent terms, and [[Nonlinear Newmark-Beta Integration]] shows how the dynamic residual is solved in time.
The dynamic buckling thesis uses MITC4 as the shell element for a full analysis program, then validates it through patch tests, linear shell benchmarks, geometric nonlinear response, static buckling, and dynamic buckling examples.
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] places MITC in the broader shell FE reliability problem: mixed interpolation should reduce [[Shell Locking Phenomenon]] in bending and mixed-dominated shells while preserving consistency and ellipticity in membrane-dominated shells.
## Why It Matters
Low-order shell elements are computationally attractive, but thin-shell bending exposes shear locking if the element cannot represent near-zero transverse shear strain. MITC4 preserves the economy of a four-node quadrilateral while making the element usable across thick and thin shells.
## Implementation Notes
The source describes an [[OOFEM]] implementation. The element stiffness follows the standard `B^T D B` volume integral, with a shell-degenerated three-dimensional material matrix and a zero normal stress condition through the thickness.
## Validation
The paper reports patch-test verification for pure bending, pure shear, pure twist, and membrane stress states. It then uses the [[Scordelis-Lo Shell Benchmark]] to study convergence against a reference solution and an RDKT comparison.
## Sources
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
- [[MITC Study Notes]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Mixed Finite Element Formulations.md
+65
View File
@@ -0,0 +1,65 @@
---
type: concept
title: "Mixed Finite Element Formulations"
complexity: advanced
domain: computational-mechanics
aliases:
- mixed formulation
- displacement-pressure formulation
- inf-sup condition
- assumed strain formulation
created: 2026-05-28
updated: 2026-05-28
address: c-000010
tags:
- concept
- finite-element-method
- incompressibility
status: current
related:
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Isoparametric Finite Elements]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
- "[[Shell Locking Phenomenon]]"
- "[[Uniform Optimal Convergence]]"
- "[[Incompatible Mode Solid Elements]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
---
# Mixed Finite Element Formulations
## Definition
Mixed finite element formulations approximate more than one primary field, such as displacement and pressure, instead of relying only on displacement unknowns.
## How It Works
Additional field variables are introduced to represent constraints or stress-like quantities directly. For incompressible or nearly incompressible media, displacement/pressure formulations separate volumetric constraint behavior from deviatoric deformation. Stability depends on compatible interpolation choices, often summarized by the inf-sup condition.
The four-node shell paper is not simply a displacement/pressure mixed formulation, but it uses the same reliability idea: a constrained or separately assumed field can remove locking when direct displacement interpolation is too restrictive.
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] adds the shell-specific stability view: MITC-style mixed interpolation is useful because it can reduce locking, but the chosen strain field still has to retain consistency, ellipticity, and thickness-uniform convergence.
[[Solid Element Notes]] adds another local enrichment pattern: incompatible mode solid elements introduce internal deformation modes and statically condense them, improving element flexibility without adding global nodal unknowns.
## Why It Matters
Mixed formulations are needed when displacement-only elements lock, produce spurious pressure modes, or fail to represent constrained fields accurately. The source treats the inf-sup condition as a central test of whether the chosen interpolation spaces are stable.
## Connections
- [[Isoparametric Finite Elements]] supplies the element construction machinery.
- [[Nonlinear Finite Element Analysis]] uses mixed formulations for large deformation incompressible behavior.
- [[Finite Element Heat Transfer and Field Problems]] uses analogous ideas when multiple fields interact.
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
- [[Solid Element Notes]]
wiki/concepts/Nonlinear Finite Element Analysis.md
+67
View File
@@ -0,0 +1,67 @@
---
type: concept
title: "Nonlinear Finite Element Analysis"
complexity: advanced
domain: computational-mechanics
aliases:
- nonlinear FEA
- incremental finite element analysis
created: 2026-05-28
updated: 2026-05-28
address: c-000011
tags:
- concept
- finite-element-method
- nonlinear-analysis
status: current
related:
- "[[Finite Element Method]]"
- "[[Mixed Finite Element Formulations]]"
- "[[Static Equilibrium Equation Solvers]]"
- "[[Direct Time Integration Methods]]"
- "[[Total Lagrangian Shell Formulation]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Green-Lagrange Strain Linearization]]"
- "[[Nonlinear Newmark-Beta Integration]]"
- "[[Geometric Stiffness Matrix]]"
- "[[Dynamic Buckling Analysis]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Nonlinear Finite Element Analysis
## Definition
Nonlinear finite element analysis solves models where the response is not a linear function of the unknowns because of geometry changes, nonlinear material behavior, contact, follower loads, or other state-dependent effects.
## How It Works
The response is advanced incrementally. At each load or time step, the equations are linearized about the current configuration, a tangent system is solved, the configuration or state variables are updated, and convergence is checked. The source organizes this through total Lagrangian and updated Lagrangian descriptions, material constitutive updates, contact conditions, and practical convergence criteria.
The four-node shell paper gives a focused structural example: a [[Total Lagrangian Shell Formulation]] is used for large displacement and rotation shell response under small strain assumptions, with benchmark problems that include snap-through, buckling, and elastoplastic plate response.
The MITC study notes add the algebraic bridge from nonlinear kinematics to solution: Green-Lagrange strain is linearized for tangent construction, and nonlinear Newmark-beta time integration embeds Newton iteration inside each dynamic time step.
The dynamic buckling thesis uses geometric nonlinearity to build the geometric stiffness terms required for buckling eigenvalue problems, then validates the resulting program against static, vibration, and dynamic buckling benchmarks.
## Why It Matters
Many engineering failures, large deformation behaviors, buckling events, contact interactions, and elastoplastic responses cannot be captured by a single linear solve. Nonlinear analysis adds physical realism but also adds dependence on increments, tangent quality, convergence tests, and path-following strategy.
## Practical Questions
- What nonlinearity dominates: geometry, material, contact, or loading?
- Is the tangent matrix consistent with the residual?
- Are increments small enough to follow the equilibrium path?
- Do convergence criteria reflect the physical quantity of interest?
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[MITC Study Notes]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Nonlinear Newmark-Beta Integration.md
+53
View File
@@ -0,0 +1,53 @@
---
type: concept
title: "Nonlinear Newmark-Beta Integration"
complexity: advanced
domain: computational-mechanics
created: 2026-05-28
updated: 2026-05-28
address: c-000031
aliases:
- nonlinear Newmark method
- Newmark-beta Newton iteration
- implicit Newmark nonlinear dynamics
tags:
- concept
- finite-element-method
- dynamics
- nonlinear-analysis
status: current
related:
- "[[MITC Study Notes]]"
- "[[Direct Time Integration Methods]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[Static Equilibrium Equation Solvers]]"
sources:
- "[[MITC Study Notes]]"
---
# Nonlinear Newmark-Beta Integration
## Definition
Nonlinear Newmark-beta integration combines Newmark time-discretization kinematics with Newton-Raphson iteration to solve nonlinear finite element dynamic equilibrium at each time step.
## How It Works
The study notes start from dynamic equilibrium with mass, stiffness, and external load terms. At the new time step, the residual depends on displacement, velocity, and acceleration. Newmark-beta relations express velocity and acceleration increments in terms of the unknown displacement increment, so the Newton system can be written as an effective tangent equation for that displacement increment.
## Why It Matters
For nonlinear structural dynamics, a time step is not just a matrix update. Internal force and tangent stiffness depend on the current trial displacement, so each step requires repeated residual evaluation, tangent assembly, displacement correction, and velocity/acceleration update until convergence.
## Iteration Skeleton
- Predict or initialize the new-step displacement, velocity, and acceleration.
- Assemble residual from external load, inertia, and internal force.
- Form the effective tangent with mass and nonlinear tangent contributions.
- Solve for the displacement correction.
- Update displacement, velocity, and acceleration using Newmark-beta formulas.
- Repeat until the residual and/or correction satisfies convergence criteria.
## Sources
- [[MITC Study Notes]]
wiki/concepts/Persistent Wiki Artifact.md
-44
View File
@@ -1,44 +0,0 @@
---
type: concept
title: "Persistent Wiki Artifact"
created: 2026-04-24
updated: 2026-04-24
tags:
- llm-wiki
- knowledge-management
- agent-memory
status: developing
related:
- "[[How does the LLM Wiki pattern work?]]"
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[Source-First Synthesis]]"
- "[[Query-Time Retrieval]]"
---
# Persistent Wiki Artifact
A persistent wiki artifact is the maintained Markdown layer between raw sources and future questions. In Karpathy's LLM Wiki description, the agent reads source material, extracts key information, and integrates it into an interlinked wiki instead of only retrieving chunks at answer time: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
## Boundary Filled
The selected question explains that an LLM Wiki compounds knowledge, but it does not isolate the artifact as the unit of memory. This page makes that boundary explicit: memory is stored in files that can be browsed, linked, reviewed, and revised.
## Extracted Claims
- The LLM Wiki pattern defines raw sources, the generated wiki, and a schema document as separate layers: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- In that pattern, the raw source collection is treated as immutable, while the wiki layer is owned and maintained by the LLM: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The pattern frames the wiki as a compounding artifact whose cross-references, contradiction flags, and synthesis persist across later questions: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Obsidian supports Wikilinks such as `[[Three laws of motion]]`, which lets Markdown files form an internal network of notes: https://obsidian.md/help/links
- Obsidian can automatically update internal links when a file is renamed, depending on the vault setting: https://obsidian.md/help/links
## Implications for This Vault
- The durable memory object is the page, not the chat turn.
- The page needs frontmatter, stable title, wikilinks, and source URLs so later agents can inspect provenance.
- The page should remain small enough to revise directly, because the LLM Wiki pattern depends on updating existing synthesis when new sources arrive: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
## Primary Sources
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- https://obsidian.md/help/links
wiki/concepts/Pro Hub Challenge.md
-60
View File
@@ -1,60 +0,0 @@
---
type: concept
title: "Pro Hub Challenge"
created: 2026-04-14
updated: 2026-04-14
tags:
- concept
- community
- ai-marketing-hub
- claude-seo
- open-source
status: evergreen
related:
- "[[Claude SEO]]"
- "[[2026-04-14-claude-seo-v190-session]]"
- "[[Semantic Topic Clustering]]"
- "[[Search Experience Optimization]]"
---
# Pro Hub Challenge
A community challenge hosted in the [AI Marketing Hub Pro](https://www.skool.com/ai-marketing-hub-pro) Skool community where members build extensions for Claude SEO or Claude Blog, competing for $600 in Claude Credits.
## First Challenge (v1.9.0, April 2026)
**6 submissions, 5 scored Proficient or above**
| Contributor | Submission | Score | Integrated? |
|------------|------------|-------|-------------|
| Lutfiya Miller | Semantic Cluster Engine | Winner | Yes — `seo-cluster` |
| Florian Schmitz | SXO Skill | Proficient | Yes — `seo-sxo` |
| Dan Colta | SEO Drift Monitor | Proficient | Yes — `seo-drift` |
| Chris Muller | Multi-lingual Blog | Proficient | Partial — SEO parts into `seo-hreflang` |
| Matej Marjanovic | E-commerce + Cost Config | Proficient | Yes — `seo-ecommerce` + cost guardrails |
| Benjamin Samar | SEO Dungeon | Reviewed | No — not integrated in v1.9.0 |
## Integration Pattern
Community submissions go through:
1. **Full code review** — architecture, quality, security
2. **Security audit** — SSRF, injection, credential handling
3. **Cherry-pick** — only SEO-relevant parts for claude-seo, blog parts stay for claude-blog
4. **De-brand** — remove contributor-specific branding (e.g., ScienceExperts.ai)
5. **Attribution** — `original_author` in SKILL.md frontmatter, HTML comments in agents, CONTRIBUTORS.md
## Submission Guidelines (from CONTRIBUTING.md)
1. SKILL.md under 500 lines, references under 200 lines
2. All scripts must import `validate_url()` for SSRF protection
3. Include `original_author` in SKILL.md frontmatter metadata
4. Submit via PR or post in AI Marketing Hub community
## Second Challenge (April 2026)
**Keyword**: LEADS
**Prize pool**: $600 ($400 first place, $200 second place) in Claude Credits
**Deadline**: April 28, 2026
**Scope**: Anything touching lead generation — Claude Code skills, n8n workflows, MCP servers, scrapers, dashboards, pipelines. If it helps someone capture, qualify, nurture, or convert leads, it counts.
**Rules**: GitHub repo or .zip file + 1-2 minute demo video. Must be functional (not a concept). Solo or team both welcome.
**Previous winner**: Lutfiya Miller (seo-cluster, integrated in v1.9.0)
wiki/concepts/Query-Time Retrieval.md
-44
View File
@@ -1,44 +0,0 @@
---
type: concept
title: "Query-Time Retrieval"
created: 2026-04-24
updated: 2026-04-24
tags:
- rag
- retrieval
- llm-wiki
status: developing
related:
- "[[How does the LLM Wiki pattern work?]]"
- "[[Wiki vs RAG]]"
- "[[LLM Wiki Pattern]]"
- "[[Persistent Wiki Artifact]]"
- "[[Source-First Synthesis]]"
---
# Query-Time Retrieval
Query-time retrieval is the baseline memory pattern that LLM Wiki is contrasted against: relevant material is retrieved when the user asks a question, and the answer is generated from the retrieved context.
## Boundary Filled
The selected question contrasts wiki accumulation with RAG, but it does not define the retrieval side precisely. This page anchors the contrast in the original RAG paper and in the LLM Wiki gist.
## Extracted Claims
- The RAG paper defines retrieval-augmented generation as combining parametric memory with non-parametric memory for language generation: https://arxiv.org/abs/2005.11401
- The RAG paper describes the non-parametric memory as a dense vector index of Wikipedia accessed with a neural retriever: https://arxiv.org/abs/2005.11401
- The paper reports that RAG models generated more specific, diverse, and factual language than a parametric-only seq2seq baseline in its evaluated generation tasks: https://arxiv.org/abs/2005.11401
- Karpathy's LLM Wiki gist describes common document workflows as uploading files, retrieving relevant chunks at query time, and generating an answer: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Karpathy's LLM Wiki gist states that this query-time pattern makes the model rediscover and assemble knowledge on each question instead of accumulating synthesis: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The MemGPT paper frames limited LLM context windows as a constraint for extended conversations and document analysis, then proposes virtual context management across memory tiers: https://arxiv.org/abs/2310.08560
## Contrast With Wiki Memory
Query-time retrieval can provide external evidence at answer time. The LLM Wiki pattern shifts part of the work earlier by compiling source material into maintained pages before later queries arrive: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
## Primary Sources
- https://arxiv.org/abs/2005.11401
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- https://arxiv.org/abs/2310.08560
wiki/concepts/SEO Drift Monitoring.md
-43
View File
@@ -1,43 +0,0 @@
---
type: concept
title: "SEO Drift Monitoring"
created: 2026-04-14
updated: 2026-04-14
tags:
- concept
- seo
- monitoring
- change-detection
status: evergreen
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
---
# SEO Drift Monitoring
"Git for SEO" — captures baselines of SEO-critical page elements, then diffs against current state to detect regressions. Contributed to [[Claude SEO]] v1.9.0 by Dan Colta.
## What It Tracks
17 comparison rules across 3 severity levels:
| Severity | Examples |
|----------|----------|
| CRITICAL | Schema removed, canonical changed, noindex added, H1 removed |
| WARNING | Title changed, CWV regression >20%, meta description changed |
| INFO | H2 structure changed, content hash changed, image count changed |
## Architecture
- **SQLite persistence** at `~/.cache/claude-seo/drift/baselines.db`
- **4 Python scripts**: `drift_baseline.py` (capture), `drift_compare.py` (diff), `drift_report.py` (HTML report), `drift_history.py` (timeline)
- **Security-hardened**: uses only `fetch_page.py` for URL fetching (SSRF-protected). Original submission had a curl fallback that bypassed SSRF protection — completely removed during integration.
## Commands
```
/seo drift baseline <url> # Capture current state
/seo drift compare <url> # Compare against baseline
/seo drift history <url> # Show all checks over time
```
wiki/concepts/SVG Diagram Style Guide.md
-159
View File
@@ -1,159 +0,0 @@
---
type: concept
title: "SVG Diagram Style Guide"
created: 2026-04-14
updated: 2026-04-14
tags:
- design
- svg
- brand
- diagrams
status: evergreen
related:
- "[[index]]"
sources:
- "claude-ads/assets/diagrams/ (17 SVGs, v1.5.0)"
---
# SVG Diagram Style Guide
The canonical visual style for all diagrams across agricidaniel's Claude Code skill repos. Extracted from the 17 production SVGs in claude-ads. Use this as the reference when creating or updating diagrams for any skill repo.
## Font
```
font-family: 'Space Grotesk', system-ui, -apple-system, sans-serif
```
Space Grotesk is the only typeface. No fallback to serif or monospace.
## Color Palette
### Core (use these in every diagram)
| Token | Hex | Role |
|-------|-----|------|
| bg | #0A0A0A | Canvas background (near-black) |
| card | #111111 | Card/container fill |
| card-inner | #1A1A1A | Nested element fill |
| border | #2D2D2D | Card borders, dividers |
| text-primary | #F5F5F0 | Headings, labels (off-white) |
| text-secondary | #888888 | Descriptions, captions |
| text-tertiary | #6a6a6a | De-emphasized metadata |
| accent | #E07850 | Primary accent, arrows, highlights (warm rust-orange) |
| accent-bright | #FF6B35 | Secondary accent, hover states (brighter orange) |
### Platform/Category Colors (use for variety within a diagram)
| Token | Hex | Typical use |
|-------|-----|-------------|
| blue | #60A5FA | Google, data, information |
| purple | #8b5cf6 | Meta, strategy, creative |
| cyan | #06b6d4 | LinkedIn, networking |
| green | #4ADE80 | Success, validation, TikTok |
| rose | #F43F5E | YouTube, alerts |
| orange | #FF6B35 | Microsoft, secondary accent |
| gray | #888888 | Neutral, generic platforms |
### Status Colors (for pass/warn/fail indicators)
| Token | Hex | Role |
|-------|-----|------|
| pass | #16a34a | Pass, success |
| warn | #f59e0b | Warning, attention |
| fail | #dc2626 | Fail, critical |
## Typography Scale
| Element | Size | Weight | Color | Extra |
|---------|------|--------|-------|-------|
| Diagram title | 16-17px | 700 | #F5F5F0 | text-anchor: middle |
| Subtitle | 11px | 400 | #888888 | text-anchor: middle |
| Section label | 13px | 700 | accent color | letter-spacing: 2 |
| Card heading | 12-15px | 600-700 | #F5F5F0 | text-anchor: middle |
| Card subtext | 9-11px | 400 | accent color | Skill/agent name |
| Body text | 10px | 400 | #888888 | Descriptions |
| Tiny label | 9px | 400 | #6a6a6a | Metadata, counts |
## Layout Primitives
### Outer Container
```xml
<rect width="800" height="500" fill="#0A0A0A"/>
```
Standard canvas is 800x500. Some diagrams use 900x250 or 900x350 depending on content.
### Card
```xml
<rect x="40" y="20" width="720" height="120" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
```
- Corner radius: `rx="16"` for outer containers
- Border: `#2D2D2D`, `stroke-width="1.5"`
### Colored Top Bar (card accent)
```xml
<rect x="40" y="20" width="720" height="4" rx="2" fill="#E07850"/>
```
4px height, sits at the top edge of the card. Color indicates category.
### Inner Card (nested element)
```xml
<rect x="60" y="230" width="105" height="60" rx="6" fill="#1A1A1A" stroke="#2D2D2D" stroke-width="1"/>
```
- Corner radius: `rx="6"` for small inner cards, `rx="9"` for medium
- Fill: `#1A1A1A` (slightly lighter than parent card)
### Numbered Circle (for sequences)
```xml
<circle cx="138" cy="60" r="14" fill="#0A0A0A" stroke="#60A5FA" stroke-width="1.5"/>
<text x="138" y="60" font-size="12" fill="#60A5FA" text-anchor="middle" font-weight="bold" dominant-baseline="central">1</text>
```
Circle stroke color matches the step's category color.
### Arrow Connector
```xml
<line x1="400" y1="140" x2="400" y2="170" stroke="#E07850" stroke-width="1.5"/>
<polygon points="394,167 400,177 406,167" fill="#E07850"/>
```
Always `#E07850`. Vertical for flow-down, horizontal for left-to-right pipelines.
### Horizontal Divider (title underline)
```xml
<line x1="380" y1="36" x2="520" y2="36" stroke="#E07850" stroke-width="2.5" stroke-linecap="round"/>
```
Short centered line under diagram title. Always accent color.
## Diagram Types (from claude-ads)
| # | Name | Layout | Size |
|---|------|--------|------|
| 01 | Architecture | 3-layer vertical stack | 800x500 |
| 02 | Parallel Audit | Agent grid with flow | 800x500 |
| 04 | Platform Checks | Checklist columns | 800x500 |
| 05 | Quality Gates | Rule cards | 800x500 |
| 06 | How It Works | Step sequence | 900x250 |
| 07 | Data Flow | Horizontal pipeline | 900x250 |
| 08 | Industry Templates | Card grid | 900x350 |
| 10 | MCP Integration | Connection diagram | 800x500 |
| 12 | Privacy Flow | Vertical flow | 800x500 |
| 13 | Scoring Algorithm | Formula breakdown | 800x500 |
| 14 | Creative Pipeline | 5-step horizontal | 900x250 |
| 15 | Platform Grid | 2-row card grid | 900x350 |
| 16 | PDF Pipeline | Process flow | 900x250 |
| 17 | A/B Testing | Split comparison | 800x500 |
| 18 | PPC Calculators | Tool cards | 900x350 |
| 19 | Audit Lifecycle | Circular flow | 800x500 |
| 20 | Install Methods | Option cards | 900x250 |
## Rules
1. Always dark theme. Never white or light backgrounds.
2. Space Grotesk only. No other fonts.
3. #E07850 is the signature accent. Use it for arrows, highlights, and the primary visual element.
4. Cards always have #2D2D2D borders. Never borderless cards.
5. Colored top bars (4px) identify categories. One color per category, consistent across the diagram.
6. Text is always left-aligned or center-aligned. Never right-aligned.
7. No gradients, shadows, or blur filters. Flat design only.
8. Numbered circles for sequential steps. Color matches category.
9. Arrow connectors are always #E07850 with triangle tips.
10. File naming: zero-padded number prefix (01-, 02-, etc.) + kebab-case description.
wiki/concepts/Scordelis-Lo Shell Benchmark.md
+60
View File
@@ -0,0 +1,60 @@
---
type: concept
title: "Scordelis-Lo Shell Benchmark"
complexity: intermediate
domain: computational-mechanics
aliases:
- Scordelis-Lo shell
- cylindrical Scordelis-Lo shell
- Scordelis Lo roof
created: 2026-05-28
updated: 2026-05-28
address: c-000024
tags:
- concept
- finite-element-method
- shell-elements
- benchmark
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Shell Structure Asymptotic Behavior]]"
- "[[Shell Element Benchmark Testing]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC4 Shell Element]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Static Equilibrium Equation Solvers]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
---
# Scordelis-Lo Shell Benchmark
## Definition
The Scordelis-Lo shell benchmark is a classical cylindrical shell problem used to evaluate shell finite elements under bending and membrane action.
## How It Is Used
In the MITC4 source, the shell is loaded by dead weight and symmetry allows one quarter of the structure to be modeled. The response quantity is the displacement at point B, and mesh refinement is used to compare MITC4 convergence with an RDKT reference element and an analytical reference.
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] uses the Scordelis-Lo roof shell as an asymptotic-behavior example. The paper identifies it as a mixed-dominated shell benchmark with an approximate load scaling factor of `rho = 1.75`, which makes it useful for exposing locking and non-uniform convergence.
## Why It Matters
The benchmark is useful because shell elements must couple membrane and bending behavior without becoming artificially stiff. Poor shell formulations can pass simple tests yet converge slowly or incorrectly on this curved-shell problem.
## Reported Trend
The source reports MITC4 displacement magnitudes converging from about 3.43 on a `4x4` quadrilateral mesh to about 3.61 on `32x32` and `64x64` meshes. The RDKT comparison converges to about 3.60 on the same refinement sequence.
## Connections
- [[MITC4 Shell Element]] uses this benchmark as its primary performance demonstration.
- [[Continuum Mechanics Based Four-Node Shell Element]] includes the benchmark family in the broader Dvorkin-Bathe shell validation thread.
## Sources
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Search Experience Optimization.md
-44
View File
@@ -1,44 +0,0 @@
---
type: concept
title: "Search Experience Optimization (SXO)"
created: 2026-04-14
updated: 2026-04-14
tags:
- concept
- seo
- ux
- serp-analysis
status: evergreen
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
- "[[Semantic Topic Clustering]]"
---
# Search Experience Optimization (SXO)
A methodology that reads SERPs backwards to detect page-type mismatches, derives user stories from search features, and scores pages from persona perspectives. Contributed to [[Claude SEO]] v1.9.0 by Florian Schmitz.
## Core Insight
> "Read SERPs backwards" — instead of optimizing content FOR the SERP, analyze WHAT the SERP tells you about user expectations, then check if your page meets them.
## Process
1. **Page-type detection** — classify the URL as one of 8 types (Landing, Blog, Product, Hybrid, Service, Comparison, Local, Tool)
2. **SERP pattern matching** — compare what Google shows (featured snippets, PAA, ads, related searches) against what the page provides
3. **Mismatch detection** — if SERP says "users want comparison" but page is "product page", that's a mismatch
4. **User story derivation** — from SERP features, derive 4-7 personas with emotional states, barriers, goals
5. **Persona scoring** — score the page from each persona's perspective (0-100 across 4 dimensions)
6. **Wireframe generation** — IST (current) vs SOLL (ideal) wireframes with ultra-concrete placeholders
## Key Innovation
Most SEO tools analyze pages in isolation. SXO uses the SERP as a proxy for user intent — the SERP IS the research that Google already did about what users want. This makes the analysis data-driven without needing user testing.
## Command
```
/seo sxo <url>
/seo sxo wireframe <url>
```
wiki/concepts/Semantic Topic Clustering.md
-46
View File
@@ -1,46 +0,0 @@
---
type: concept
title: "Semantic Topic Clustering"
created: 2026-04-14
updated: 2026-04-14
tags:
- concept
- seo
- content-strategy
- clustering
status: evergreen
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
- "[[Search Experience Optimization]]"
---
# Semantic Topic Clustering
SERP-based keyword grouping that replaces paid tools ($50-200/month) with Claude's reasoning. Contributed to [[Claude SEO]] v1.9.0 by Lutfiya Miller (Pro Hub Challenge Winner).
## How It Works
1. **Seed keyword** provided by user
2. **SERP fetching** — get Google results for the seed and related terms (via WebSearch or DataForSEO)
3. **Overlap scoring** — compare top-10 results between keyword pairs:
- 7-10 overlapping URLs = same post (keyword cannibalization)
- 4-6 overlapping = same cluster (supporting content)
- 2-3 overlapping = interlink opportunity
- 0-1 overlapping = separate clusters
4. **Hub-spoke architecture** — 1 pillar page (2500-4000 words) + 2-5 clusters + 2-4 posts each
5. **Internal link matrix** — bidirectional linking plan with backward link injection
6. **Visualization** — interactive cluster-map.html (SVG, dark mode, keyboard accessible)
## Key Design Decisions
- **No Python scripts** — clustering is prompt-driven (Claude's reasoning + WebSearch)
- **Optional execution** — outputs content briefs when claude-blog isn't installed, full pipeline when it is
- **Resume capability** — for long multi-post execution runs
- **DataForSEO integration** — uses `serp_organic_live_advanced` for live SERP data when available (with cost check)
## Command
```
/seo cluster <seed-keyword>
```
wiki/concepts/Shell Element Benchmark Testing.md
+58
View File
@@ -0,0 +1,58 @@
---
type: concept
title: "Shell Element Benchmark Testing"
complexity: advanced
domain: computational-mechanics
aliases:
- shell benchmark testing
- shell element performance testing
- shell finite element benchmarks
created: 2026-05-28
updated: 2026-05-28
address: c-000047
tags:
- concept
- finite-element-method
- shell-elements
- benchmark
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Scordelis-Lo Shell Benchmark]]"
- "[[Shell Locking Phenomenon]]"
- "[[Uniform Optimal Convergence]]"
- "[[MITC4 Shell Element]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Shell Element Benchmark Testing
## Definition
Shell element benchmark testing is the structured evaluation of shell finite elements across basic element checks, convergence measures, shell geometries, asymptotic behavior classes, and mesh patterns.
## How It Works
The source argues that shell element performance should not be judged only from a displacement at one point. A useful test set should include zero-energy mode checks, membrane and bending patch tests, isotropy checks for triangular elements, convergence curves, and global error measures such as S-norm.
The test problems should also vary the shell's Gaussian curvature, thickness, layer behavior, asymptotic behavior, and element mesh shape. This exposes whether the element is only tuned for a narrow problem class or is robust enough for design analysis.
## Benchmark Dimensions
- Basic element checks: zero-energy modes, patch tests, and element isotropy.
- Geometry: positive, zero, and negative Gaussian curvature.
- Asymptotic behavior: bending-dominated, membrane-dominated, and mixed-dominated shell problems.
- Error view: global error norms and field distributions, not only one output point.
- Mesh sensitivity: element distortion, anisotropic meshes, and orientation effects.
## Connections
- [[Scordelis-Lo Shell Benchmark]] is one important benchmark in this family.
- [[Shell Locking Phenomenon]] is a primary failure mode benchmark tests should reveal.
- [[Uniform Optimal Convergence]] is the performance target.
- [[MITC4 Shell Element]] uses benchmark evidence to support its practical reliability.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Shell Locking Phenomenon.md
+56
View File
@@ -0,0 +1,56 @@
---
type: concept
title: "Shell Locking Phenomenon"
complexity: advanced
domain: computational-mechanics
aliases:
- shell locking
- locking phenomenon
- membrane locking
- shear locking
created: 2026-05-28
updated: 2026-05-28
address: c-000045
tags:
- concept
- finite-element-method
- shell-elements
- locking
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Assumed Transverse Shear Strain Interpolation]]"
- "[[MITC4 Shell Element]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Shell Structure Asymptotic Behavior]]"
- "[[Uniform Optimal Convergence]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Shell Locking Phenomenon
## Definition
Shell locking is a thickness-dependent finite element error in which a shell element becomes artificially stiff as the shell becomes thin. It appears as underpredicted displacements, stresses, strains, and strain energy, and as poor convergence in thin-shell bending or mixed-dominated problems.
## How It Works
The source connects locking to [[Shell Structure Asymptotic Behavior]]. Displacement-based shell elements may fail to approximate the pure bending displacement space of the [[Basic Shell Mathematical Model]]. The result is parasitic membrane or transverse shear strain in states that should be nearly strain-free in those modes.
The paper distinguishes membrane locking from shear locking. Membrane locking appears in curved shells, while transverse shear locking can appear regardless of curvature when the interpolation cannot represent the thin-shell bending constraint.
## Remedies
Common remedies include reduced integration, incompatible or non-conforming modes, ANS, EAS, and MITC-style mixed interpolation. The source treats MITC as a particularly effective family because it interpolates selected tensorial strain components at tying points while trying to retain consistency and ellipticity.
## Connections
- [[Assumed Transverse Shear Strain Interpolation]] is the targeted shear-locking remedy used in the four-node shell thread.
- [[MITC4 Shell Element]] is the practical low-order shell element thread that uses mixed interpolation to control locking.
- [[Uniform Optimal Convergence]] is the desired behavior after locking has been controlled.
- [[Shell Element Benchmark Testing]] describes how locking should be exposed using convergence curves and thickness variation.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Shell Structure Asymptotic Behavior.md
+55
View File
@@ -0,0 +1,55 @@
---
type: concept
title: "Shell Structure Asymptotic Behavior"
complexity: advanced
domain: computational-mechanics
aliases:
- shell asymptotic behavior
- bending-dominated shell behavior
- membrane-dominated shell behavior
- mixed-dominated shell behavior
created: 2026-05-28
updated: 2026-05-28
address: c-000044
tags:
- concept
- finite-element-method
- shell-elements
- asymptotics
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Basic Shell Mathematical Model]]"
- "[[Shell Locking Phenomenon]]"
- "[[Uniform Optimal Convergence]]"
- "[[Scordelis-Lo Shell Benchmark]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Shell Structure Asymptotic Behavior
## Definition
Shell structure asymptotic behavior is the limiting response class of a shell as the thickness ratio becomes small. The source classifies thin-shell behavior into bending-dominated, membrane-dominated, and mixed-dominated regimes.
## How It Works
The paper writes the simplified shell variational problem in terms of a thickness ratio and separates bending energy from membrane and shear energy. A load scaling factor `rho` indicates how the shell stiffness scales with thickness. Values near `rho = 1` indicate membrane-dominated behavior, values near `rho = 3` indicate bending-dominated behavior, and intermediate values indicate mixed-dominated behavior.
The classification depends on geometry, boundary conditions, and loading. The key mathematical object is the pure bending displacement space: if pure bending is available and the loading excites it, bending-dominated behavior can appear; if not, membrane or mixed behavior controls.
## Why It Matters
The same shell element can appear reliable in one shell problem and lock or converge slowly in another. Shell asymptotic behavior explains why benchmark problems must vary thickness, curvature, boundary conditions, and loading rather than relying on one fixed-thickness result.
## Connections
- [[Basic Shell Mathematical Model]] supplies the bending and membrane energy terms.
- [[Shell Locking Phenomenon]] is strongly tied to whether an element can approximate the pure bending space.
- [[Uniform Optimal Convergence]] asks whether convergence remains optimal across thickness and asymptotic regimes.
- [[Scordelis-Lo Shell Benchmark]] is cited as a shell problem whose asymptotic behavior can be evaluated numerically.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/Solid Element Shape Functions.md
+59
View File
@@ -0,0 +1,59 @@
---
type: concept
title: "Solid Element Shape Functions"
complexity: intermediate
domain: computational-mechanics
aliases:
- solid element interpolation functions
- linear solid shape functions
- tetrahedral wedge pyramid hexahedral shape functions
created: 2026-05-28
updated: 2026-05-28
address: c-000050
tags:
- concept
- finite-element-method
- solid-elements
- interpolation
status: current
related:
- "[[Solid Element Notes]]"
- "[[Isoparametric Linear Solid Elements]]"
- "[[Isoparametric Finite Elements]]"
- "[[Solid Element Strain-Displacement Matrix]]"
sources:
- "[[Solid Element Notes]]"
---
# Solid Element Shape Functions
## Definition
Solid element shape functions interpolate three-dimensional element geometry and displacement from nodal values in natural coordinates.
## Covered Topologies
The notes give first-order interpolation for four common solid element shapes:
- 4-node tetrahedron with barycentric-style coordinates.
- 5-node pyramid connecting a quadrilateral base to an apex.
- 6-node wedge, or triangular prism, using triangular interpolation through a two-node thickness direction.
- 8-node hexahedron with trilinear interpolation in `xi`, `eta`, and `zeta`.
## Why They Matter
Shape functions are the starting point for every later element calculation. They define the displacement approximation, the geometry mapping, the Jacobian, the derivative transformation, and ultimately the strain-displacement matrix. Because the same functions interpolate geometry and field variables, the source is a concrete example of [[Isoparametric Finite Elements]].
## Modeling Implications
Low-order solid shape functions are economical but sensitive to distortion and limited in bending-dominated response. This is why element aspect ratio and topology selection matter before any solver choice is considered.
## Connections
- [[Isoparametric Linear Solid Elements]] gives the element-level context.
- [[Solid Element Strain-Displacement Matrix]] differentiates these functions after Jacobian mapping.
- [[Solid Element Stiffness Integration]] integrates the resulting `B^T D B` expression over the element volume.
## Sources
- [[Solid Element Notes]]
wiki/concepts/Solid Element Stiffness Integration.md
+59
View File
@@ -0,0 +1,59 @@
---
type: concept
title: "Solid Element Stiffness Integration"
complexity: advanced
domain: computational-mechanics
aliases:
- solid element stiffness matrix
- solid element Gauss integration
- 3D element quadrature
created: 2026-05-28
updated: 2026-05-28
address: c-000052
tags:
- concept
- finite-element-method
- solid-elements
- numerical-integration
status: current
related:
- "[[Solid Element Notes]]"
- "[[Solid Element Strain-Displacement Matrix]]"
- "[[Isoparametric Finite Elements]]"
- "[[Displacement-Based Finite Element Formulation]]"
sources:
- "[[Solid Element Notes]]"
---
# Solid Element Stiffness Integration
## Definition
Solid element stiffness integration evaluates the element stiffness matrix for a three-dimensional continuum element by numerically integrating `B^T D B` over the element volume.
## How It Works
The source uses the standard displacement-based stiffness form:
```text
K = integral_V B^T D B dV
= integral B^T D B |J| dxi deta dzeta
```
Here `B` is the [[Solid Element Strain-Displacement Matrix]], `D` is the three-dimensional Hooke-law constitutive matrix, and `|J|` is the determinant of the Jacobian that maps the natural-coordinate integration region to physical volume.
The notes list quadrature schemes for the first-order solid topologies: one-point integration for the 4-node tetrahedron, eight-point integration for the 5-node pyramid, six-point integration for the 6-node wedge, and eight-point integration for the 8-node hexahedron.
## Why It Matters
The stiffness integral is where interpolation, material law, element distortion, and numerical quadrature meet. Incorrect quadrature or a poor Jacobian can produce inaccurate stiffness, spurious mechanisms, or poor convergence even when the symbolic formulation is correct.
## Connections
- [[Isoparametric Finite Elements]] supplies the natural-coordinate integration framework.
- [[Solid Element Shape Functions]] and [[Solid Element Strain-Displacement Matrix]] define the integrand.
- [[Incompatible Mode Solid Elements]] modifies the displacement field and therefore expands the stiffness matrix before static condensation.
## Sources
- [[Solid Element Notes]]
wiki/concepts/Solid Element Strain-Displacement Matrix.md
+63
View File
@@ -0,0 +1,63 @@
---
type: concept
title: "Solid Element Strain-Displacement Matrix"
complexity: advanced
domain: computational-mechanics
aliases:
- solid element B matrix
- 3D strain-displacement matrix
- Jacobian derivative mapping
created: 2026-05-28
updated: 2026-05-28
address: c-000051
tags:
- concept
- finite-element-method
- solid-elements
- strain-displacement
status: current
related:
- "[[Solid Element Notes]]"
- "[[Displacement-Based Finite Element Formulation]]"
- "[[Isoparametric Finite Elements]]"
- "[[Solid Element Shape Functions]]"
- "[[Solid Element Stiffness Integration]]"
sources:
- "[[Solid Element Notes]]"
---
# Solid Element Strain-Displacement Matrix
## Definition
The solid element strain-displacement matrix, usually called the `B` matrix, maps nodal translational degrees of freedom to the six small-strain components of a three-dimensional continuum element.
## How It Works
The notes use the standard small-strain components:
- normal strains: `epsilon_xx`, `epsilon_yy`, `epsilon_zz`
- engineering shear terms derived from `epsilon_xy`, `epsilon_yz`, and `epsilon_xz`
Each node contributes a block of derivatives of its shape function with respect to physical coordinates:
```text
[ dN_i/dx 0 0 ]
[ 0 dN_i/dy 0 ]
[ 0 0 dN_i/dz ]
[ dN_i/dy dN_i/dx 0 ]
[ 0 dN_i/dz dN_i/dy]
[ dN_i/dz 0 dN_i/dx]
```
Because [[Solid Element Shape Functions]] are defined in natural coordinates, their derivatives must be mapped into physical coordinates through the Jacobian. This derivative mapping is the core computational step between interpolation and stiffness assembly.
## Connections
- [[Displacement-Based Finite Element Formulation]] supplies the general `epsilon = B u` path.
- [[Isoparametric Finite Elements]] explains why the Jacobian appears.
- [[Solid Element Stiffness Integration]] uses this `B` matrix in `K = integral B^T D B dV`.
## Sources
- [[Solid Element Notes]]
wiki/concepts/Source-First Synthesis.md
-42
View File
@@ -1,42 +0,0 @@
---
type: concept
title: "Source-First Synthesis"
created: 2026-04-24
updated: 2026-04-24
tags:
- llm-wiki
- synthesis
- provenance
status: developing
related:
- "[[How does the LLM Wiki pattern work?]]"
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[Persistent Wiki Artifact]]"
- "[[Query-Time Retrieval]]"
---
# Source-First Synthesis
Source-first synthesis is the LLM Wiki practice of keeping raw sources separate from the generated wiki while requiring the wiki to cite and integrate those sources. Karpathy's pattern describes raw sources as the source of truth and the generated wiki as the maintained synthesis layer: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
## Boundary Filled
The selected question says the wiki pattern integrates sources, but it does not spell out the provenance discipline. This page records the rule: synthesis is allowed to be rewritten, but source material remains the cited anchor.
## Extracted Claims
- Karpathy's LLM Wiki pattern says raw sources can include articles, papers, images, and data files, and that the LLM reads them without modifying them: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The same source describes the wiki as summaries, entity pages, concept pages, comparisons, overview, and synthesis maintained by the LLM: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The ingest operation can create a source summary, update indexes, update relevant entity and concept pages, and append a log entry: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The query operation reads relevant wiki pages and synthesizes answers with citations, and useful answers can be filed back into the wiki: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- The RAG paper identifies provenance and updating world knowledge as open problems for knowledge-intensive generation systems: https://arxiv.org/abs/2005.11401
## Operating Rule
Source-first synthesis is stricter than unsourced summarization. A new concept page should identify the sources it used, state what was extracted from them, and avoid treating the generated page as a replacement for the source document.
## Primary Sources
- https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- https://arxiv.org/abs/2005.11401
wiki/concepts/Static Equilibrium Equation Solvers.md
+53
View File
@@ -0,0 +1,53 @@
---
type: concept
title: "Static Equilibrium Equation Solvers"
complexity: advanced
domain: computational-mechanics
aliases:
- static finite element solvers
- finite element equation solution
created: 2026-05-28
updated: 2026-05-28
address: c-000013
tags:
- concept
- finite-element-method
- linear-solvers
status: current
related:
- "[[Finite Element Method]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[Geometric Stiffness Matrix]]"
- "[[Dynamic Buckling Analysis]]"
- "[[Finite Element Program Implementation]]"
sources:
- "[[Finite Element Procedures]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Static Equilibrium Equation Solvers
## Definition
Static equilibrium equation solvers compute the unknown finite element degrees of freedom for time-independent systems, usually after assembly of stiffness and load terms.
## How It Works
For linear systems, the source covers direct methods based on Gauss elimination, LDL^T, Cholesky factorization, active-column storage, static condensation, substructuring, and frontal solution. For large sparse systems, iterative methods such as Gauss-Seidel and preconditioned conjugate gradient are discussed. For nonlinear static systems, Newton-Raphson, BFGS, load-displacement-constraint methods, and convergence criteria enter.
The dynamic buckling thesis uses static nonlinear formulation to produce geometric stiffness for buckling analysis, so static equilibrium solution is part of the route to instability prediction.
## Why It Matters
The finite element method produces algebraic systems whose solution cost and numerical stability can dominate the analysis. Solver choice depends on matrix symmetry, definiteness, sparsity, conditioning, model size, and whether the equations are linear or nonlinear.
## Connections
- [[Nonlinear Finite Element Analysis]] uses nonlinear static solvers inside incremental equilibrium.
- [[Finite Element Program Implementation]] handles storage, assembly, and equation solution.
- [[Finite Element Eigenproblem Solvers]] uses related matrix factorizations and definiteness concepts.
## Sources
- [[Finite Element Procedures]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Total Lagrangian Shell Formulation.md
+64
View File
@@ -0,0 +1,64 @@
---
type: concept
title: "Total Lagrangian Shell Formulation"
complexity: advanced
domain: computational-mechanics
aliases:
- total Lagrangian shell analysis
- large displacement shell formulation
- large rotation shell formulation
created: 2026-05-28
updated: 2026-05-28
address: c-000021
tags:
- concept
- finite-element-method
- shell-elements
- nonlinear-analysis
status: current
related:
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[MITC Shell Kinematics]]"
- "[[Green-Lagrange Strain Linearization]]"
- "[[Geometric Stiffness Matrix]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[Nonlinear Finite Element Analysis]]"
- "[[Static Equilibrium Equation Solvers]]"
sources:
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Total Lagrangian Shell Formulation
## Definition
A total Lagrangian shell formulation writes the nonlinear shell equilibrium equations with respect to the initial reference configuration, even while the shell undergoes large displacement and rotation response.
## How It Works
The formulation tracks kinematic measures, stress resultants, and virtual work using the original configuration as the reference. In the four-node shell paper, this framework is used for large displacement and rotation analysis under the assumption of small strains, with shell director behavior and thickness assumptions built into the element kinematics.
The MITC study notes make the tangent path explicit by writing Green-Lagrange strain in the reference configuration, pairing it with second Piola-Kirchhoff stress, and separating strain terms for incremental Newton solution.
The dynamic buckling thesis uses the total Lagrangian formulation to derive the [[Geometric Stiffness Matrix]] needed for static and dynamic buckling analysis of MITC4 shell models.
## Why It Matters
Large shell rotations, snap-through behavior, buckling paths, and elastoplastic response require incremental nonlinear analysis. A total Lagrangian statement gives a consistent reference frame for deriving residuals and tangent stiffness terms in such problems.
## Connections
- [[Nonlinear Finite Element Analysis]] is the broader incremental equilibrium framework.
- [[Continuum Mechanics Based Four-Node Shell Element]] uses this formulation for nonlinear shell examples.
- [[Green-Lagrange Strain Linearization]] is the local strain expansion used to build residual and tangent terms.
- [[Static Equilibrium Equation Solvers]] solve the load-step equilibrium equations that result from the formulation.
## Sources
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[MITC Study Notes]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/concepts/Uniform Optimal Convergence.md
+54
View File
@@ -0,0 +1,54 @@
---
type: concept
title: "Uniform Optimal Convergence"
complexity: advanced
domain: computational-mechanics
aliases:
- uniform optimal convergence
- thickness-uniform convergence
- optimal shell convergence
created: 2026-05-28
updated: 2026-05-28
address: c-000046
tags:
- concept
- finite-element-method
- shell-elements
- convergence
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Shell Locking Phenomenon]]"
- "[[Shell Structure Asymptotic Behavior]]"
- "[[Shell Element Benchmark Testing]]"
- "[[Mixed Finite Element Formulations]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Uniform Optimal Convergence
## Definition
Uniform optimal convergence means that a shell finite element converges at its expected approximation rate and that this behavior remains stable as shell thickness changes and as the problem moves between membrane, bending, and mixed-dominated regimes.
## How It Works
For shell elements, optimal convergence alone is not enough if it holds only for one fixed thickness or one convenient benchmark. The paper frames the ideal shell element as one that keeps optimal convergence uniformly across shell shapes, boundary conditions, loads, and asymptotic behavior classes.
For mixed shell formulations, this requirement is closely related to the inf-sup condition. For practical benchmarking, the source uses convergence curves and S-norm style global error measurement rather than only point displacement comparisons.
## Why It Matters
A shell element can pass simple checks and still fail in thin-shell bending because of locking. Uniform optimal convergence is the stronger standard that separates a generally reliable shell element from one that only works in selected examples.
## Connections
- [[Shell Locking Phenomenon]] is the failure mode this criterion detects.
- [[Shell Element Benchmark Testing]] describes the evidence needed to evaluate the criterion.
- [[Mixed Finite Element Formulations]] provides the stability context, including inf-sup reasoning.
- [[MITC4 Shell Element]] is a practical element family whose value is judged by convergence under locking-prone problems.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/concepts/_index.md
+43 -16
View File
@@ -6,37 +6,64 @@ tags:
- meta
- index
- concept
domain: knowledge-management
domain: computational-mechanics
status: evergreen
related:
- "[[index]]"
- "[[dashboard]]"
- "[[Wiki Map]]"
- "[[Hot Cache]]"
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[LLM Wiki Pattern]]"
- "[[Hot Cache]]"
- "[[Compounding Knowledge]]"
- "[[Computational Mechanics]]"
- "[[Finite Element Method]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
- "[[MITC4 Shell Element]]"
- "[[MITC Shell Kinematics]]"
- "[[Dynamic Buckling Analysis]]"
- "[[Shell Structure Asymptotic Behavior]]"
- "[[Isoparametric Linear Solid Elements]]"
---
# Concepts Index
Navigation: [[index]] | [[entities/_index|Entities]] | [[sources/_index|Sources]]
All concept pages — ideas, patterns, and frameworks extracted from sources.
All concept pages: finite-element and computational-mechanics concepts extracted from sources.
---
## Knowledge Management
## Computational Mechanics
- [[LLM Wiki Pattern]] — the core architecture for persistent, compounding knowledge bases
- [[Hot Cache]] — ~500-word session context file, updated after every ingest
- [[Compounding Knowledge]] — why the wiki grows more valuable over time, unlike RAG
- [[DragonScale Memory]] — memory-layer spec: fold operator, deterministic page addresses, semantic tiling, boundary-first autoresearch (status: shipped v0.4, all four mechanisms opt-in)
- [[Persistent Wiki Artifact]]: durable Markdown page as the LLM's memory object (developing)
- [[Source-First Synthesis]]: provenance discipline for LLM wiki layers (developing)
- [[Query-Time Retrieval]]: query synthesis with citations, complementary to Obsidian search (developing)
- [[Finite Element Method]] - numerical procedure for solving discretized engineering and physics models
- [[Engineering Mathematical Models]] - idealized physical models selected before finite element solution
- [[Displacement-Based Finite Element Formulation]] - primary solid mechanics formulation using nodal displacements
- [[Isoparametric Finite Elements]] - shape-function framework for geometry mapping and element matrix calculation
- [[Isoparametric Linear Solid Elements]] - first-order 3D continuum elements using isoparametric interpolation
- [[Solid Element Shape Functions]] - interpolation functions for tetrahedral, pyramid, wedge, and hexahedral solid elements
- [[Solid Element Strain-Displacement Matrix]] - 3D solid element `B` matrix and Jacobian derivative mapping
- [[Solid Element Stiffness Integration]] - numerical integration of `B^T D B` over element volume
- [[Incompatible Mode Solid Elements]] - internal-mode enrichment and static condensation for solid elements
- [[Mixed Finite Element Formulations]] - multi-field formulations for incompressibility, constraints, and pressure-like variables
- [[Nonlinear Finite Element Analysis]] - incremental solution of geometric, material, contact, and load nonlinearities
- [[Continuum Mechanics Based Four-Node Shell Element]] - low-order shell element derived from continuum mechanics for nonlinear analysis
- [[Assumed Transverse Shear Strain Interpolation]] - shell locking remedy using a separately interpolated transverse shear field
- [[Total Lagrangian Shell Formulation]] - reference-configuration formulation for large displacement and rotation shell response
- [[MITC4 Shell Element]] - four-node quadrilateral shell element using mixed interpolation of tensorial components
- [[MITC Shell Kinematics]] - director-vector kinematic model for MITC shell elements
- [[Green-Lagrange Strain Linearization]] - nonlinear strain expansion for internal force and tangent stiffness terms
- [[Nonlinear Newmark-Beta Integration]] - implicit Newmark time stepping with Newton-Raphson nonlinear iterations
- [[Dynamic Buckling Analysis]] - instability analysis of structures under time-varying compressive loading
- [[Dynamic Instability Region]] - load-frequency instability boundary for parametric buckling
- [[Geometric Stiffness Matrix]] - initial stress stiffness contribution used in nonlinear and buckling analysis
- [[Scordelis-Lo Shell Benchmark]] - cylindrical shell benchmark for shell element convergence and locking behavior
- [[Basic Shell Mathematical Model]] - midsurface/director shell model underlying continuum shell finite elements
- [[Shell Structure Asymptotic Behavior]] - bending, membrane, and mixed thin-shell response classes
- [[Shell Locking Phenomenon]] - membrane and shear locking as artificial stiffness in thin-shell FE solutions
- [[Uniform Optimal Convergence]] - thickness-uniform optimal convergence target for shell elements
- [[Shell Element Benchmark Testing]] - structured performance testing for shell finite elements
- [[Finite Element Heat Transfer and Field Problems]] - finite element treatment of heat transfer, field equations, flow, and coupled problems
- [[Static Equilibrium Equation Solvers]] - direct, iterative, and nonlinear solvers for static FE equations
- [[Direct Time Integration Methods]] - transient finite element dynamics and first-order field integration
- [[Finite Element Eigenproblem Solvers]] - modal and eigenvalue algorithms for FE matrices
- [[Finite Element Program Implementation]] - software data flow for FE codes and STAP-style implementation
---
wiki/domains/Computational Mechanics.md
+63
View File
@@ -0,0 +1,63 @@
---
type: domain
title: "Computational Mechanics"
created: 2026-05-28
updated: 2026-05-28
address: c-000005
tags:
- domain
- computational-mechanics
- finite-element-method
status: current
related:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
- "[[Finite Element Method]]"
- "[[Engineering Mathematical Models]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
---
# Computational Mechanics
## Scope
Computational mechanics uses numerical methods to model, discretize, and solve physical problems in solids, structures, heat transfer, fluids, field problems, and coupled multiphysics systems. This vault currently enters the domain through [[Finite Element Procedures]], [[Solid Element Notes]], the shell element paper [[A Continuum Mechanics Based Four-Node Shell]], the MITC4 implementation paper [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]], [[MITC Study Notes]], the shell buckling thesis [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]], and the shell FE review [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]].
## Core Threads
- [[Engineering Mathematical Models]] - how physical problems become solvable mathematical models.
- [[Finite Element Method]] - the central discretization workflow.
- [[Displacement-Based Finite Element Formulation]] - the primary formulation for linear solid and structural mechanics.
- [[Isoparametric Finite Elements]] - the element construction and matrix computation framework.
- [[Isoparametric Linear Solid Elements]], [[Solid Element Shape Functions]], [[Solid Element Strain-Displacement Matrix]], [[Solid Element Stiffness Integration]], and [[Incompatible Mode Solid Elements]] - 3D continuum solid element formulation and enrichment.
- [[Mixed Finite Element Formulations]] - stable formulations for incompressibility and constrained fields.
- [[Nonlinear Finite Element Analysis]] - incremental, iterative treatment of geometric, material, and contact nonlinearities.
- [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], and [[Total Lagrangian Shell Formulation]] - shell-element formulation details for nonlinear thin and thick shell analysis.
- [[MITC4 Shell Element]] and [[Scordelis-Lo Shell Benchmark]] - implementation-oriented shell element validation and locking assessment.
- [[Basic Shell Mathematical Model]], [[Shell Structure Asymptotic Behavior]], [[Shell Locking Phenomenon]], [[Uniform Optimal Convergence]], and [[Shell Element Benchmark Testing]] - shell FE reliability criteria for thin-shell behavior and element testing.
- [[MITC Shell Kinematics]], [[Green-Lagrange Strain Linearization]], and [[Nonlinear Newmark-Beta Integration]] - derivation-level bridge from shell kinematics to nonlinear dynamics.
- [[Dynamic Buckling Analysis]], [[Dynamic Instability Region]], and [[Geometric Stiffness Matrix]] - stability workflow for dynamically compressed shell and plate structures.
- [[Static Equilibrium Equation Solvers]], [[Direct Time Integration Methods]], and [[Finite Element Eigenproblem Solvers]] - solver families for different equation types.
- [[Finite Element Program Implementation]] - the practical data flow from input to element calculations, assembly, solution, and stress recovery.
## Current Source Base
- [[Finite Element Procedures]] by [[Klaus-Jurgen Bathe]].
- [[Solid Element Notes]] from `.raw/SolidElement/`.
- [[A Continuum Mechanics Based Four-Node Shell]] by [[Eduardo N. Dvorkin]] and [[Klaus-Jurgen Bathe]].
- [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]] by [[Edita Dvorakova]] and [[Borek Patzak]].
- [[MITC Study Notes]] from `.raw/MITC공부/`.
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]] by [[Hee Jun Lee]].
- [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]] by [[Phill-Seung Lee]] and [[Hyuk-Chun Noh]].
wiki/domains/_index.md
+27
View File
@@ -0,0 +1,27 @@
---
type: meta
title: "Domains Index"
updated: 2026-05-28
tags:
- meta
- index
- domain
status: evergreen
related:
- "[[index]]"
- "[[Computational Mechanics]]"
---
# Domains Index
Navigation: [[index]] | [[concepts/_index|Concepts]] | [[entities/_index|Entities]] | [[sources/_index|Sources]]
---
## Active Domains
- [[Computational Mechanics]] - finite element analysis, numerical methods, and engineering simulation.
---
## Add new domains here after each ingest.
wiki/entities/ABAQUS.md
+35
View File
@@ -0,0 +1,35 @@
---
type: entity
title: "ABAQUS"
entity_type: software
role: "Commercial finite element software used for validation comparisons"
first_mentioned: "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000036
tags:
- entity
- software
- finite-element-method
- validation
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Finite Element Program Implementation]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# ABAQUS
## Overview
ABAQUS is the commercial finite element software used as a comparison reference in the dynamic buckling thesis.
## Role In The Source
The thesis compares the developed finite element program against ABAQUS for linear static shell benchmarks, geometric nonlinear response, and static buckling eigenvalue and mode-shape checks.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/entities/Andrej Karpathy.md
-47
View File
@@ -1,47 +0,0 @@
---
type: entity
title: "Andrej Karpathy"
entity_type: person
role: "AI researcher, educator, founder"
first_mentioned: "[[LLM Wiki Pattern]]"
created: 2026-04-07
updated: 2026-04-07
tags:
- entity
- person
- ai-researcher
status: mature
related:
- "[[LLM Wiki Pattern]]"
- "[[Compounding Knowledge]]"
- "[[entities/_index]]"
sources:
---
# Andrej Karpathy
AI researcher and educator. Former Director of AI at Tesla, founding member of OpenAI. Known for deep learning education (Neural Networks: Zero to Hero series, micrograd, nanoGPT) and for publishing practical AI patterns.
---
## Key Contributions to This Wiki
Karpathy originated the [[LLM Wiki Pattern]] — the idea of using LLMs to build and maintain a persistent, compounding knowledge base rather than re-deriving knowledge from raw documents on every query.
He published the idea as an "idea file" — intentionally abstract, designed to be copy-pasted into a Claude Code or similar session and built out collaboratively. The claude-obsidian plugin is a production implementation of this pattern.
His framing: "The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read."
---
## Notable Quote
"I thought that I had to reach for fancy RAG, but the LLM has been pretty good at auto-maintaining index files and brief summaries of all documents and reads all the important related data fairly easily at this small scale."
---
## Connections
- [[LLM Wiki Pattern]] — his core contribution to knowledge management
- [[Compounding Knowledge]] — the central insight he articulated
- claude-obsidian plugin — this repo is a production implementation of his pattern
wiki/entities/BLZPACK.md
+41
View File
@@ -0,0 +1,41 @@
---
type: entity
title: "BLZPACK"
entity_type: software
role: "Block Lanczos eigenvalue solver used for vibration and buckling analysis"
first_mentioned: "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000035
tags:
- entity
- software
- eigenproblem
- finite-element-method
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Finite Element Eigenproblem Solvers]]"
- "[[Dynamic Buckling Analysis]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# BLZPACK
## Overview
BLZPACK is identified in the dynamic buckling thesis as an open-source eigenvalue analysis solver based on the Block Lanczos method.
## Role In The Source
The thesis uses BLZPACK for eigenvalue analyses needed in vibration analysis, static buckling analysis, and dynamic buckling analysis workflows.
## Connections
- [[Finite Element Eigenproblem Solvers]] gives the broader numerical context.
- [[Geometric Stiffness Matrix]] appears in the static and dynamic buckling eigenvalue problems where such solvers are needed.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/entities/Borek Patzak.md
+39
View File
@@ -0,0 +1,39 @@
---
type: entity
title: "Borek Patzak"
entity_type: person
role: "Finite element researcher; co-author of the MITC4 shell element paper"
first_mentioned: "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000026
tags:
- entity
- finite-element-method
- shell-elements
- implementation
status: current
related:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[Edita Dvorakova]]"
- "[[OOFEM]]"
- "[[MITC4 Shell Element]]"
sources:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
---
# Borek Patzak
## Overview
Borek Patzak is identified in the MITC4 source as a co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4]] and is affiliated there with the Department of Mechanics, Faculty of Civil Engineering, Czech Technical University in Prague.
## Key Facts
- Co-author of the MITC4 shell element paper with [[Edita Dvorakova]].
- Connected in the source to [[OOFEM]], where the MITC4 shell element implementation is reported.
- The source references earlier work by Patzak and Bittnar on object-oriented finite element code design.
## Sources
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
wiki/entities/Claude SEO.md
-74
View File
@@ -1,74 +0,0 @@
---
type: entity
title: "Claude SEO"
created: 2026-04-14
updated: 2026-04-15
tags:
- entity
- project
- claude-code
- seo
status: evergreen
related:
- "[[Pro Hub Challenge]]"
- "[[2026-04-14-claude-seo-v190-session]]"
- "[[Semantic Topic Clustering]]"
- "[[Search Experience Optimization]]"
- "[[SEO Drift Monitoring]]"
- "[[E-commerce SEO]]"
- "[[2026-04-15-slides-and-release-session]]"
- "[[2026-04-15-release-report-session]]"
---
# Claude SEO
A Tier 4 Claude Code skill for comprehensive SEO analysis across all industries. Repository: [AgriciDaniel/claude-seo](https://github.com/AgriciDaniel/claude-seo)
## Current State (v1.9.0 — released April 15, 2026)
- **23 skills** (20 core + 3 extensions: DataForSEO, Firecrawl, Banana)
- **17 subagents** (15 core + 2 extension agents)
- **30 Python scripts** (28 tracked + 2 dev-only)
- **Architecture**: 3-layer (directive, orchestration, execution)
- **Entry point**: `/seo [command] [url]`
- **GitHub release**: [v1.9.0](https://github.com/AgriciDaniel/claude-seo/releases/tag/v1.9.0) — PDF report attached
- **Slides**: `claude-seo-slides/v190.html` — 15-slide community presentation deck
- **Contributors**: 6 submissions, 5 integrated (Lutfiya Miller, Florian Schmitz, Dan Colta, Matej Marjanovic, Chris Muller)
## Key Commands
| Category | Commands |
|----------|----------|
| Analysis | audit, page, technical, content, schema, images, geo |
| Planning | plan, cluster, sxo, programmatic, competitor-pages |
| Monitoring | drift baseline, drift compare, drift history |
| Local | local, maps |
| International | hreflang (with cultural profiles) |
| E-commerce | ecommerce |
| Data | google, backlinks, dataforseo |
| Generation | sitemap, image-gen |
## Version History
| Version | Date | Key Addition |
|---------|------|-------------|
| v1.9.0 | 2026-04-15 | Pro Hub Challenge: cluster, SXO, drift, ecommerce, cost guardrails, cultural profiles. GitHub release + PDF report + 15-slide deck. |
| v1.8.2 | 2026-04-10 | Ukrainian localization, CI fixes, version sync |
| v1.8.1 | 2026-04-06 | Google Images SERP, image optimization |
| v1.8.0 | 2026-03-31 | Free backlink data (Moz, Bing, Common Crawl) |
| v1.7.0 | 2026-03-28 | Google SEO APIs (GSC, PageSpeed, CrUX, GA4) |
## Ecosystem
- [[Claude SEO]] — SEO analysis (this project)
- Claude Blog — companion blog engine, consumes SEO findings
- Claude Banana — AI image generation, bundled as extension
- AI Marketing Claude — community marketing suite by Zubair Trabzada
## Security Posture (v1.9.0 audit)
- **Score**: 85/100 (Grade B+)
- **SSRF protection**: validate_url() + fetch_page.py DNS resolution
- **SQL**: all queries parameterized
- **Cost guardrails**: threshold approval, daily limits, file locking, audit trail
- **Pre-existing debt**: validate_url DNS rebinding gap, install script injection, OAuth file permissions
wiki/entities/Edita Dvorakova.md
+37
View File
@@ -0,0 +1,37 @@
---
type: entity
title: "Edita Dvorakova"
entity_type: person
role: "Finite element researcher; co-author of the MITC4 shell element paper"
first_mentioned: "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000025
tags:
- entity
- finite-element-method
- shell-elements
status: current
related:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[Borek Patzak]]"
- "[[MITC4 Shell Element]]"
sources:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
---
# Edita Dvorakova
## Overview
Edita Dvorakova is identified in the MITC4 source as a co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4]] and is affiliated there with the Department of Mechanics, Faculty of Civil Engineering, Czech Technical University in Prague.
## Key Facts
- Co-author of the MITC4 shell element paper with [[Borek Patzak]].
- Connected in this vault to shell finite element formulation, MITC interpolation, and [[OOFEM]] implementation.
- The source extraction contains encoding artifacts; this page uses an ASCII transliteration of the author name.
## Sources
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
wiki/entities/Eduardo N. Dvorkin.md
+44
View File
@@ -0,0 +1,44 @@
---
type: entity
title: "Eduardo N. Dvorkin"
entity_type: person
role: "Finite element researcher; co-author of the four-node shell element paper"
first_mentioned: "[[A Continuum Mechanics Based Four-Node Shell]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000018
tags:
- entity
- finite-element-method
- shell-elements
- computational-mechanics
status: current
related:
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Klaus-Jurgen Bathe]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
sources:
- "[[A Continuum Mechanics Based Four-Node Shell]]"
---
# Eduardo N. Dvorkin
## Overview
Eduardo N. Dvorkin is identified in the ingested source as a co-author, with [[Klaus-Jurgen Bathe]], of the paper on a continuum-mechanics-based four-node shell element for nonlinear analysis.
## Key Facts
- Co-author of [[A Continuum Mechanics Based Four-Node Shell]].
- The paper places the work in the Department of Mechanical Engineering at Massachusetts Institute of Technology.
- In this vault, Dvorkin is connected to shell finite element formulation, transverse shear locking remedies, and nonlinear structural analysis.
## Connections
- [[Continuum Mechanics Based Four-Node Shell Element]] captures the paper's element formulation.
- [[Assumed Transverse Shear Strain Interpolation]] captures the paper's key locking remedy.
- [[Total Lagrangian Shell Formulation]] captures the nonlinear kinematic setting.
## Sources
- [[A Continuum Mechanics Based Four-Node Shell]]
wiki/entities/Hee Jun Lee.md
+39
View File
@@ -0,0 +1,39 @@
---
type: entity
title: "Hee Jun Lee"
entity_type: person
role: "Author of the dynamic shell buckling finite element thesis"
first_mentioned: "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000033
aliases:
- "이희준"
tags:
- entity
- finite-element-method
- dynamic-buckling
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Inha University]]"
- "[[Dynamic Buckling Analysis]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Hee Jun Lee
## Overview
Hee Jun Lee is the author of the 2012 Inha University master's thesis [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]].
## Key Facts
- Affiliated in the source with the Department of Aerospace Engineering, Graduate School of [[Inha University]].
- The thesis develops a finite element program for dynamic buckling analysis of shell structures under axial dynamic compression.
- The source identifies Cho Jin Yeon as advisor and lists committee members Kim Ki Wook, Cho Jin Yeon, and Lee Seung Soo.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/entities/Hyuk-Chun Noh.md
+47
View File
@@ -0,0 +1,47 @@
---
type: entity
title: "Hyuk-Chun Noh"
entity_type: person
role: "Shell finite element researcher and author"
first_mentioned: "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000042
aliases:
- "H.C. Noh"
- "Noh, H.C."
tags:
- entity
- finite-element-method
- shell-elements
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Phill-Seung Lee]]"
- "[[Shell Element Benchmark Testing]]"
- "[[Shell Locking Phenomenon]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Hyuk-Chun Noh
## Overview
Hyuk-Chun Noh is listed as an author of [[On-the-Finite-Element-Analysis-of-Shell-Structures]] with [[Phill-Seung Lee]]. In this vault, Noh is connected to shell finite element evaluation, element isotropy, mesh-pattern effects, and shell benchmark methodology.
## Key Facts
- Co-author of the ingested Korean review on shell finite element analysis.
- Appears in the source reference thread through shell element and structural shell work, including triangular shell element insight and cooling tower shell behavior.
- The source uses this thread to argue that shell element performance must be checked against asymptotic behavior, curvature, layer behavior, and mesh patterns.
## Connections
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]] is the ingested source.
- [[Shell Element Benchmark Testing]] captures the testing methodology connected to mesh pattern and element isotropy.
- [[Shell Locking Phenomenon]] captures the main failure mode the benchmark methodology tries to expose.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/entities/Inha University.md
+34
View File
@@ -0,0 +1,34 @@
---
type: entity
title: "Inha University"
entity_type: organization
role: "Degree-granting institution for the dynamic shell buckling thesis"
first_mentioned: "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000034
tags:
- entity
- organization
- finite-element-method
status: current
related:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[Hee Jun Lee]]"
sources:
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
---
# Inha University
## Overview
Inha University is the institution named in [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]] as the graduate school where the thesis was submitted.
## Role In The Source
The thesis is identified as a master's thesis from the Department of Aerospace Engineering, Graduate School of Inha University, submitted in February 2012.
## Sources
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]
wiki/entities/Klaus-Jurgen Bathe.md
+54
View File
@@ -0,0 +1,54 @@
---
type: entity
title: "Klaus-Jurgen Bathe"
entity_type: person
role: "Professor of Mechanical Engineering; finite element method author"
first_mentioned: "[[Finite Element Procedures]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000004
tags:
- entity
- finite-element-method
- computational-mechanics
status: current
related:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Eduardo N. Dvorkin]]"
- "[[Finite Element Method]]"
- "[[Continuum Mechanics Based Four-Node Shell Element]]"
sources:
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Klaus-Jurgen Bathe
## Overview
Klaus-Jurgen Bathe is the author of `Finite Element Procedures` and is identified in the source as Professor of Mechanical Engineering at Massachusetts Institute of Technology. He is also a co-author, with [[Eduardo N. Dvorkin]], of [[A Continuum Mechanics Based Four-Node Shell]]. In this vault, he is a primary source authority for finite element procedures and shell element formulation.
[[On-the-Finite-Element-Analysis-of-Shell-Structures]] thanks Bathe and repeatedly uses Bathe-linked shell finite element work as the reference thread for asymptotic behavior, locking, MITC elements, and benchmark testing.
## Key Facts
- Author of `Finite Element Procedures`, second edition.
- Co-author of the continuum-mechanics-based four-node shell element paper.
- The source text emphasizes finite element analysis as a modeling discipline, not only a matrix-solving procedure.
- The book includes theory, algorithms, implementation guidance, and educational program material.
## Connections
- [[Finite Element Procedures]] is the ingested source.
- [[A Continuum Mechanics Based Four-Node Shell]] is the ingested shell element paper.
- [[Finite Element Method]] is the central method developed across the source.
- [[Finite Element Program Implementation]] captures the implementation path from the book.
## Sources
- [[Finite Element Procedures]]
- [[A Continuum Mechanics Based Four-Node Shell]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/entities/OOFEM.md
+42
View File
@@ -0,0 +1,42 @@
---
type: entity
title: "OOFEM"
entity_type: software
role: "Finite element code used for the MITC4 shell element implementation"
first_mentioned: "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000027
tags:
- entity
- software
- finite-element-method
- implementation
status: current
related:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC4 Shell Element]]"
- "[[Finite Element Program Implementation]]"
- "[[Borek Patzak]]"
sources:
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
---
# OOFEM
## Overview
OOFEM is the finite element code named in the MITC4 source as the implementation target for the four-node quadrilateral shell element.
## Role In The Source
The source reports that the [[MITC4 Shell Element]] was implemented in OOFEM and verified with patch tests before being exercised on the [[Scordelis-Lo Shell Benchmark]].
## Connections
- [[Finite Element Program Implementation]] gives the broader finite element software context.
- [[Borek Patzak]] is connected to OOFEM through the source references and authorship.
## Sources
- [[Four-Node-Quadrilateral-Shell-Element-MITC4]]
wiki/entities/Phill-Seung Lee.md
+48
View File
@@ -0,0 +1,48 @@
---
type: entity
title: "Phill-Seung Lee"
entity_type: person
role: "Shell finite element researcher and author"
first_mentioned: "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
created: 2026-05-28
updated: 2026-05-28
address: c-000041
aliases:
- "P.S. Lee"
- "Lee, P.S."
tags:
- entity
- finite-element-method
- shell-elements
status: current
related:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Hyuk-Chun Noh]]"
- "[[Klaus-Jurgen Bathe]]"
- "[[Shell Structure Asymptotic Behavior]]"
- "[[Shell Element Benchmark Testing]]"
sources:
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Phill-Seung Lee
## Overview
Phill-Seung Lee is listed as an author of [[On-the-Finite-Element-Analysis-of-Shell-Structures]] with [[Hyuk-Chun Noh]]. In this vault, Lee is relevant for shell finite element fundamentals, especially asymptotic behavior, benchmark evaluation, and thickness-sensitive shell discretization issues.
## Key Facts
- Co-author of the ingested Korean review on shell finite element analysis.
- Cited throughout the source's reference thread with [[Klaus-Jurgen Bathe]] on shell asymptotic behavior, basic shell mathematical models, MITC shell evaluation, and triangular shell element behavior.
- Connected to the source's practical message: shell FE results should be interpreted through physical behavior, mathematical model, and convergence evidence.
## Connections
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]] is the ingested source.
- [[Shell Structure Asymptotic Behavior]] and [[Shell Element Benchmark Testing]] capture the main technical themes tied to Lee's cited work.
- [[Uniform Optimal Convergence]] is the performance standard used to judge shell elements across thickness regimes.
## Sources
- [[On-the-Finite-Element-Analysis-of-Shell-Structures]]
wiki/entities/_index.md
+28 -7
View File
@@ -9,34 +9,55 @@ tags:
status: evergreen
related:
- "[[index]]"
- "[[Andrej Karpathy]]"
- "[[hot]]"
- "[[LLM Wiki Pattern]]"
- "[[Klaus-Jurgen Bathe]]"
- "[[Eduardo N. Dvorkin]]"
- "[[Edita Dvorakova]]"
- "[[Borek Patzak]]"
- "[[OOFEM]]"
- "[[Hee Jun Lee]]"
- "[[Phill-Seung Lee]]"
- "[[Hyuk-Chun Noh]]"
- "[[Inha University]]"
- "[[BLZPACK]]"
- "[[ABAQUS]]"
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
---
# Entities Index
Navigation: [[index]] | [[concepts/_index|Concepts]] | [[sources/_index|Sources]]
All entity pages — people, organizations, products, and tools.
All entity pages: people, organizations, products, and tools.
---
## People
- [[Andrej Karpathy]] — AI researcher, educator; originated the LLM Wiki pattern
- [[Klaus-Jurgen Bathe]] - professor of mechanical engineering, author of [[Finite Element Procedures]], and co-author of [[A Continuum Mechanics Based Four-Node Shell]]
- [[Eduardo N. Dvorkin]] - co-author of [[A Continuum Mechanics Based Four-Node Shell]]
- [[Edita Dvorakova]] - co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]]
- [[Borek Patzak]] - co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]]
- [[Hee Jun Lee]] - author of [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]]
- [[Phill-Seung Lee]] - author of [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]]
- [[Hyuk-Chun Noh]] - author of [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]]
---
## Organizations
<!-- Add organization pages here -->
- [[Inha University]] - degree-granting institution for the dynamic shell buckling thesis
---
## Products & Tools
<!-- Add tool and product pages here -->
- [[OOFEM]] - finite element code used for the MITC4 shell element implementation
- [[BLZPACK]] - Block Lanczos eigenvalue solver used for vibration and buckling analysis
- [[ABAQUS]] - finite element software used for validation comparisons
---
wiki/folds/fold-k3-from-2026-04-23-to-2026-04-24-n8.md
-115
View File
@@ -1,115 +0,0 @@
---
type: fold
title: "Fold k3 - 2026-04-23 to 2026-04-24 - n8"
fold_id: "fold-k3-from-2026-04-23-to-2026-04-24-n8"
batch_exponent: 3
n: 8
entry_count: 8
earliest: "2026-04-23"
latest: "2026-04-24"
entry_range:
from: "2026-04-23"
to: "2026-04-24"
created: "2026-04-24"
updated: "2026-04-24"
tags:
- meta
- fold
- "fold/k3"
status: mature
children:
- date: "2026-04-24"
op: "save"
title: "v1.6.0 closeout (Teams, chair-led)"
page: "[[2026-04-24-v1.6.0-release-session]]"
page_missing: false
- date: "2026-04-24"
op: "save"
title: "DragonScale Phase 4 - boundary-first autoresearch shipped (v1.6.0)"
page: "[[DragonScale Memory]]"
page_missing: false
- date: "2026-04-24"
op: "save"
title: "DragonScale Phase 3.5 - cross-phase hardening to v1.5.0"
page: "[[DragonScale Memory]]"
page_missing: false
- date: "2026-04-24"
op: "save"
title: "DragonScale Phase 3 - semantic tiling MVP"
page: "[[DragonScale Memory]]"
page_missing: false
- date: "2026-04-23"
op: "save"
title: "DragonScale Phase 2 - deterministic page addresses MVP"
page: "[[DragonScale Memory]]"
page_missing: false
- date: "2026-04-23"
op: "save"
title: "DragonScale Phase 1 - wiki-fold skill shipped"
page: "[[wiki-fold]]"
page_missing: false
- date: "2026-04-23"
op: "save"
title: "DragonScale Memory v0.2 - post-adversarial-review"
page: "[[DragonScale Memory]]"
page_missing: false
- date: "2026-04-23"
op: "save"
title: "DragonScale Memory - Phase 0 design doc (proposed)"
page: "[[DragonScale Memory]]"
page_missing: false
related:
- "[[DragonScale Memory]]"
- "[[log]]"
- "[[index]]"
---
Level-3 fold of 8 log entries spanning 2026-04-23 to 2026-04-24. Dominant themes: staged DragonScale implementation, adversarial review gates, release and test hardening.
## Child Entries
| Date | Op | Title | Page | Summary (extractive) |
|---|---|---|---|---|
| 2026-04-24 | save | v1.6.0 closeout (Teams, chair-led) | [[2026-04-24-v1.6.0-release-session]] | Release closeout recorded new release-session, boundary-frontier, and DragonScale guide artifacts; all 11 verifier items were applied and `make test` passed. |
| 2026-04-24 | save | DragonScale Phase 4 - boundary-first autoresearch shipped (v1.6.0) | [[DragonScale Memory]] | Boundary-first autoresearch shipped as opt-in topic selection, surfacing top-5 frontier pages when `/autoresearch` has no topic. |
| 2026-04-24 | save | DragonScale Phase 3.5 - cross-phase hardening to v1.5.0 | [[DragonScale Memory]] | Cross-phase audit hardening resolved 10 hold-ship items, added a reproducible test harness, and version-bumped plugin metadata to 1.5.0. |
| 2026-04-24 | save | DragonScale Phase 3 - semantic tiling MVP | [[DragonScale Memory]] | Semantic tiling shipped as opt-in embedding-based duplicate detection with `scripts/tiling-check.py`, threshold state, lint wiring, and a final 10/10 accept verdict. |
| 2026-04-23 | save | DragonScale Phase 2 - deterministic page addresses MVP | [[DragonScale Memory]] | Deterministic page addresses shipped with `c-NNNNNN` allocation, flock-guarded concurrency, lint checks, manifest idempotency, and an 8/8 accept verdict. |
| 2026-04-23 | save | DragonScale Phase 1 - wiki-fold skill shipped | [[wiki-fold]] | Wiki-fold shipped as a flat extractive rollup skill with dry-run stdout default, deterministic fold IDs, duplicate detection, and a 7/7 accept verdict. |
| 2026-04-23 | save | DragonScale Memory v0.2 - post-adversarial-review | [[DragonScale Memory]] | The v0.2 concept revision weakened claims, added operational policies and provenance tags, and reached 7/7 accepted after one surgical fix. |
| 2026-04-23 | save | DragonScale Memory - Phase 0 design doc (proposed) | [[DragonScale Memory]] | The Phase 0 design proposed four memory-layer mechanisms and recorded verified primary sources for dragon curve, paperfolding, LSM trees, MemGPT, and Anthropic prompt caching. |
## Key Outcomes
- The Phase 0 design proposed four memory-layer mechanisms: fold operator, content-addressable page paths, semantic tiling lint, and boundary-first autoresearch scoring (from 2026-04-23 Phase 0 design doc entry).
- The v0.2 concept revision changed load-bearing claims after adversarial review and reached 7/7 accepted after one surgical fix on tagging-scope language (from 2026-04-23 post-adversarial-review entry).
- The wiki-fold skill shipped with dry-run stdout, deterministic `fold_id`, duplicate-range detection, and a final 7/7 accept verdict (from 2026-04-23 Phase 1 entry).
- Deterministic page addresses shipped with `c-NNNNNN` format, flock-guarded allocation, counter recovery, manifest-preserved path-to-address mapping, and an 8/8 accept verdict (from 2026-04-23 Phase 2 entry).
- Semantic tiling shipped with opt-in ollama `nomic-embed-text` duplicate detection, conservative default bands, cache invalidation, locking, scale guards, and final 10/10 accept (from 2026-04-24 Phase 3 entry).
- Cross-phase hardening to v1.5.0 resolved 10 hold-ship items and added tests covering 12 shell assertions plus 18 python assertions (from 2026-04-24 Phase 3.5 entry).
- Boundary-first autoresearch shipped as v1.6.0 and the log records that all four DragonScale mechanisms are now shipped and opt-in (from 2026-04-24 Phase 4 entry).
- The v1.6.0 closeout applied all 11 verifier items across 6 files and `make test` passed with 12 shell assertions, 18 tiling assertions, and 44 boundary-score assertions (from 2026-04-24 closeout entry).
## Cross-entry Themes
- DragonScale progressed by gated phases from design proposal to shipped opt-in mechanisms (supported by: 2026-04-23 Phase 0, 2026-04-23 Phase 1, 2026-04-23 Phase 2, 2026-04-24 Phase 3, 2026-04-24 Phase 4 entries).
- Adversarial review was used as a repeated acceptance gate, with explicit accept counts recorded in concept revision, wiki-fold, address assignment, semantic tiling, Phase 4, and closeout entries (supported by: 2026-04-23 post-adversarial-review, 2026-04-23 Phase 1, 2026-04-23 Phase 2, 2026-04-24 Phase 3, 2026-04-24 Phase 4, 2026-04-24 closeout entries).
- Release hardening added tests, docs, changelog, version metadata, and guide updates around the DragonScale mechanisms (supported by: 2026-04-24 Phase 3.5, 2026-04-24 Phase 4, 2026-04-24 closeout entries).
## Contradictions or Corrections
- The 2026-04-24 closeout entry records applied corrections: install-guide wording changed from hierarchical log folds to flat extractive log folds, boundary-frontier provenance was corrected to `--top 7`, and hot.md tag wording was corrected from local tag only to local commits only. Resolution: applied in the closeout entry.
## Child Pages
- [[2026-04-24-v1.6.0-release-session]]
- [[boundary-frontier-2026-04-24]]
- [[DragonScale Memory]]
- [[wiki-fold]]
- [[fold-template]]
## Related
- [[DragonScale Memory]] - fold-operator spec and DragonScale mechanism record
- [[log]] - source entries
- [[index]] - vault catalog
wiki/getting-started.md
+59 -70
View File
@@ -1,7 +1,7 @@
---
type: meta
title: "Getting Started"
updated: 2026-04-07
updated: 2026-05-28
tags:
- meta
- onboarding
@@ -9,92 +9,81 @@ status: evergreen
related:
- "[[index]]"
- "[[overview]]"
- "[[LLM Wiki Pattern]]"
- "[[Wiki vs RAG]]"
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
- "[[Finite Element Method]]"
- "[[Wiki Map]]"
---
# Getting Started with claude-obsidian
# Getting Started
Welcome. This vault is your compounding knowledge base — a persistent second brain built with Claude and Obsidian.
Every source you add gets processed into 8–15 cross-referenced wiki pages. Every question you ask pulls from everything that's been ingested. Knowledge compounds like interest.
This vault is currently organized around finite element procedures and computational mechanics.
---
## Three-Step Quick Start
## Navigation
### 1. Drop a source
Put any document into the `.raw/` folder:
- PDFs, markdown files, transcripts, articles
- Or paste a URL and ask Claude to fetch it
### 2. Ingest it
Tell Claude in any Claude Code session:
```
ingest [filename]
```
Claude reads the source, creates 8–15 wiki pages under `wiki/`, cross-references everything, and updates `wiki/index.md`, `wiki/log.md`, and `wiki/hot.md`.
### 3. Ask questions
```
what do you know about [topic]?
```
Claude reads the hot cache, scans the index, drills into relevant pages, and gives you a synthesized answer — citing specific wiki pages, not training data.
- [[index]] - master catalog of current wiki pages
- [[overview]] - short summary of the vault scope
- [[hot]] - recent context cache for future sessions
- [[log]] - operation log, currently trimmed to 2026-05-28 entries
- [[Wiki Map]] - visual map of the current finite-element wiki
- [[dashboard]] - Obsidian Bases dashboard
---
## How the Hot Cache Works
## Current Source
`wiki/hot.md` is a ~500-word summary of recent vault context. It loads automatically at the start of every session (via the SessionStart hook).
You don't need to recap. Claude starts every session knowing what you've been working on.
Update it manually at any time: `update hot cache`
- [[Finite Element Procedures]] by [[Klaus-Jurgen Bathe]]
- [[A Continuum Mechanics Based Four-Node Shell]] by [[Eduardo N. Dvorkin]] and [[Klaus-Jurgen Bathe]]
- [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]] by [[Edita Dvorakova]] and [[Borek Patzak]]
- [[MITC Study Notes]]
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]] by [[Hee Jun Lee]]
- [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]] by [[Phill-Seung Lee]] and [[Hyuk-Chun Noh]]
- [[Solid Element Notes]]
---
## Your First Ingest — Walkthrough
## Current Domain
1. Create a file in `.raw/` — copy a transcript, paste an article, or save a PDF
2. Open Claude Code in this vault folder
3. Type: `ingest [your-filename]`
4. Watch the wiki grow — Claude will report which pages it created
5. Open `wiki/index.md` — you'll see the new pages listed
6. Open Graph View in Obsidian — a new cluster of connected nodes appears
After 3–5 ingests, the graph starts to look like a real knowledge network. Cross-references emerge automatically.
- [[Computational Mechanics]]
---
## Key Commands
## Query Starting Points
| You say | Claude does |
|---------|-------------|
| `ingest [file]` | Creates 8–15 wiki pages from a source |
| `what do you know about X?` | Queries the wiki, cites pages |
| `/save` | Files this conversation as a wiki note |
| `/autoresearch [topic]` | Searches the web, ingests results autonomously |
| `lint the wiki` | Health check — finds orphans, gaps, stale links |
| `update hot cache` | Refreshes the session context summary |
---
## Navigate the Vault
- **[[Wiki Map]]** — visual Fibonacci graph of all wiki pages
- **[[index]]** — master catalog, all pages by type
- **[[overview]]** — executive summary of vault contents
- **[[LLM Wiki Pattern]]** — the pattern this vault is built on
- **[[Wiki vs RAG]]** — why a wiki beats RAG at human scale
- **[[dashboard]]** — live Dataview queries (requires Dataview plugin)
---
*Built on the [LLM Wiki pattern](https://github.com/karpathy) by Andrej Karpathy.*
- [[Finite Element Method]]
- [[Displacement-Based Finite Element Formulation]]
- [[Isoparametric Finite Elements]]
- [[Isoparametric Linear Solid Elements]]
- [[Solid Element Shape Functions]]
- [[Solid Element Strain-Displacement Matrix]]
- [[Solid Element Stiffness Integration]]
- [[Incompatible Mode Solid Elements]]
- [[Mixed Finite Element Formulations]]
- [[Nonlinear Finite Element Analysis]]
- [[Continuum Mechanics Based Four-Node Shell Element]]
- [[Assumed Transverse Shear Strain Interpolation]]
- [[Total Lagrangian Shell Formulation]]
- [[MITC4 Shell Element]]
- [[MITC Shell Kinematics]]
- [[Green-Lagrange Strain Linearization]]
- [[Nonlinear Newmark-Beta Integration]]
- [[Dynamic Buckling Analysis]]
- [[Dynamic Instability Region]]
- [[Geometric Stiffness Matrix]]
- [[Scordelis-Lo Shell Benchmark]]
- [[Basic Shell Mathematical Model]]
- [[Shell Structure Asymptotic Behavior]]
- [[Shell Locking Phenomenon]]
- [[Uniform Optimal Convergence]]
- [[Shell Element Benchmark Testing]]
- [[Static Equilibrium Equation Solvers]]
- [[Direct Time Integration Methods]]
- [[Finite Element Eigenproblem Solvers]]
- [[Finite Element Program Implementation]]
wiki/hot.md
+29 -10
View File
@@ -1,7 +1,7 @@
---
type: meta
title: "Hot Cache"
updated: 2026-05-28T09:45:00+09:00
updated: 2026-05-28T12:20:00+09:00
tags:
- meta
- hot-cache
@@ -10,27 +10,46 @@ related:
- "[[index]]"
- "[[log]]"
- "[[overview]]"
- "[[Finite Element Procedures]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
- "[[Finite Element Method]]"
---
# Recent Context
## Last Updated
2026-05-28. Removed the Claude + Obsidian ecosystem research source and its direct generated wiki pages so the vault can be reoriented around another domain.
2026-05-28. The wiki was trimmed to finite-element scope, then solid element, shell element, MITC, dynamic buckling, and shell finite element review sources were ingested, including `.raw/SolidElement/`.
## Key Recent Facts
- Removed `.raw/claude-obsidian-ecosystem-research.md` and `wiki/sources/claude-obsidian-ecosystem-research.md`.
- Removed direct generated pages: `claude-obsidian-ecosystem`, `cherry-picks`, `Ar9av-obsidian-wiki`, `Nexus-claudesidian-mcp`, `ballred-obsidian-claude-pkm`, `rvk7895-llm-knowledge-bases`, `kepano-obsidian-skills`, and `Claudian-YishenTu`.
- No canvas file referenced those pages, so no canvases were removed.
- Historical log, release, audit, benchmark, and report notes were preserved unless they were direct source-generated pages.
- Current sources: [[Finite Element Procedures]], [[Solid Element Notes]], [[A Continuum Mechanics Based Four-Node Shell]], [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]], [[MITC Study Notes]], [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]], and [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]].
- Current domain: [[Computational Mechanics]].
- Current core concepts: [[Finite Element Method]], [[Engineering Mathematical Models]], [[Displacement-Based Finite Element Formulation]], [[Isoparametric Finite Elements]], [[Isoparametric Linear Solid Elements]], [[Solid Element Shape Functions]], [[Solid Element Strain-Displacement Matrix]], [[Solid Element Stiffness Integration]], [[Incompatible Mode Solid Elements]], [[Mixed Finite Element Formulations]], [[Nonlinear Finite Element Analysis]], [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Total Lagrangian Shell Formulation]], [[MITC4 Shell Element]], [[MITC Shell Kinematics]], [[Green-Lagrange Strain Linearization]], [[Nonlinear Newmark-Beta Integration]], [[Dynamic Buckling Analysis]], [[Dynamic Instability Region]], [[Geometric Stiffness Matrix]], [[Scordelis-Lo Shell Benchmark]], [[Basic Shell Mathematical Model]], [[Shell Structure Asymptotic Behavior]], [[Shell Locking Phenomenon]], [[Uniform Optimal Convergence]], [[Shell Element Benchmark Testing]], [[Finite Element Heat Transfer and Field Problems]], [[Static Equilibrium Equation Solvers]], [[Direct Time Integration Methods]], [[Finite Element Eigenproblem Solvers]], and [[Finite Element Program Implementation]].
- The solid element notes contribute a 3D continuum element formulation thread: linear isoparametric solid element topologies, natural-coordinate shape functions, Jacobian derivative mapping, stiffness integration, and incompatible mode enrichment.
- The four-node shell paper contributes a continuum-mechanics shell formulation, an assumed transverse shear strain interpolation to avoid shear locking, and a total Lagrangian nonlinear shell analysis setting.
- The MITC4 source contributes an OOFEM implementation thread, patch-test verification, and Scordelis-Lo convergence data for a four-node quadrilateral shell element.
- The MITC study notes contribute derivation details: shell director kinematics, Green-Lagrange strain linearization, constitutive transformation, and nonlinear Newmark-beta iteration.
- The dynamic buckling thesis contributes a validated MITC4 shell program workflow: geometric stiffness, lumped mass, BLZPACK eigenvalue solves, ABAQUS comparisons, and instability-region prediction.
- The shell FE review contributes the conceptual reliability frame: basic shell mathematical model, bending/membrane/mixed asymptotic behavior, locking, uniform optimal convergence, and benchmark testing.
- Removed non-finite-element wiki content, old canvases, old fold pages, old question/comparison notes, old release/audit/session artifacts, and pre-2026-05-28 log entries.
## Recent Changes
- Updated: [[index]], [[overview]], [[log]], [[hot]]
- Deleted: old source files and direct source-generated pages.
- Created most recently: [[Solid Element Notes]], [[Isoparametric Linear Solid Elements]], [[Solid Element Shape Functions]], [[Solid Element Strain-Displacement Matrix]], [[Solid Element Stiffness Integration]], [[Incompatible Mode Solid Elements]]
- Previous shell review thread: [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]], [[Phill-Seung Lee]], [[Hyuk-Chun Noh]], [[Basic Shell Mathematical Model]], [[Shell Structure Asymptotic Behavior]], [[Shell Locking Phenomenon]], [[Uniform Optimal Convergence]], [[Shell Element Benchmark Testing]]
- Previous dynamic stability thread: [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]], [[Hee Jun Lee]], [[Inha University]], [[BLZPACK]], [[ABAQUS]], [[Dynamic Buckling Analysis]], [[Dynamic Instability Region]], [[Geometric Stiffness Matrix]]
- Previous MITC derivation thread: [[MITC Study Notes]], [[MITC Shell Kinematics]], [[Green-Lagrange Strain Linearization]], [[Nonlinear Newmark-Beta Integration]]
- Previous MITC implementation thread: [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]], [[MITC4 Shell Element]], [[Scordelis-Lo Shell Benchmark]], [[Edita Dvorakova]], [[Borek Patzak]], [[OOFEM]]
- Previous shell thread: [[A Continuum Mechanics Based Four-Node Shell]], [[Eduardo N. Dvorkin]], [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Total Lagrangian Shell Formulation]]
- Updated: [[index]], [[overview]], [[log]], [[hot]], [[getting-started]], [[dashboard]], [[Wiki Map]], [[sources/_index]], [[concepts/_index]], [[entities/_index]]
- Preserved: finite-element source/entity/domain/concept pages and wiki operational files.
## Active Threads
- User wants to rebuild this wiki around sources from another field.
- Next setup question: What is the new field or purpose for this vault?
- User is curating this vault as a finite element and computational mechanics wiki, now with a solid-and-shell element thread that connects 3D continuum formulation, isoparametric interpolation, stiffness integration, incompatible modes, shell asymptotic behavior, locking remedies, uniform convergence, benchmarks, nonlinear dynamics, and dynamic buckling stability prediction.
wiki/index.md
+62 -42
View File
@@ -12,18 +12,24 @@ related:
- "[[hot]]"
- "[[dashboard]]"
- "[[Wiki Map]]"
- "[[getting-started]]"
- "[[concepts/_index]]"
- "[[entities/_index]]"
- "[[sources/_index]]"
- "[[LLM Wiki Pattern]]"
- "[[Hot Cache]]"
- "[[Compounding Knowledge]]"
- "[[Andrej Karpathy]]"
- "[[domains/_index]]"
- "[[Finite Element Method]]"
- "[[Computational Mechanics]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
---
# Wiki Index
Last updated: 2026-05-28 | Total pages: 40 | Sources ingested: 0
Last updated: 2026-05-28 | Total pages: 63 | Sources ingested: 7
Navigation: [[overview]] | [[log]] | [[hot]] | [[dashboard]] | [[Wiki Map]] | [[getting-started]]
@@ -31,55 +37,69 @@ Navigation: [[overview]] | [[log]] | [[hot]] | [[dashboard]] | [[Wiki Map]] | [[
## Concepts
- [[LLM Wiki Pattern]] - the pattern for building persistent, compounding knowledge bases using LLMs (status: mature)
- [[Hot Cache]] - session context file, updated after every ingest and session (status: mature)
- [[Compounding Knowledge]] - why wiki knowledge grows more valuable over time, unlike RAG (status: mature)
- [[SVG Diagram Style Guide]] - canonical visual style for all diagrams (status: evergreen)
- [[Pro Hub Challenge]] - community challenge pattern for claude-seo and claude-blog extensions (status: evergreen)
- [[Semantic Topic Clustering]] - SERP-based keyword grouping with hub-spoke architecture (status: evergreen)
- [[Search Experience Optimization]] - SERP methodology for page-type mismatch detection and persona scoring (status: evergreen)
- [[SEO Drift Monitoring]] - baseline, diff, and track workflow for SEO changes (status: evergreen)
- [[DragonScale Memory]] - memory-layer spec with fold operator, deterministic page addresses, semantic tiling, and boundary-first autoresearch (status: shipped v0.4)
- [[Persistent Wiki Artifact]] - durable Markdown page as the LLM's memory object (status: developing)
- [[Source-First Synthesis]] - provenance discipline for raw sources and synthesized wiki layers (status: developing)
- [[Query-Time Retrieval]] - wiki query path synthesizes with citations (status: developing)
- [[Finite Element Method]] - numerical procedure for solving discretized engineering and physics models (status: current)
- [[Engineering Mathematical Models]] - idealized physical models selected before finite element solution (status: current)
- [[Displacement-Based Finite Element Formulation]] - primary solid mechanics formulation using nodal displacements (status: current)
- [[Isoparametric Finite Elements]] - shape-function framework for element geometry, interpolation, and matrices (status: current)
- [[Isoparametric Linear Solid Elements]] - first-order 3D continuum elements with translational nodal degrees of freedom (status: current)
- [[Solid Element Shape Functions]] - natural-coordinate interpolation functions for tetrahedron, pyramid, wedge, and hexahedron elements (status: current)
- [[Solid Element Strain-Displacement Matrix]] - 3D solid element `B` matrix and Jacobian derivative mapping (status: current)
- [[Solid Element Stiffness Integration]] - `B^T D B` volume integration for solid element stiffness matrices (status: current)
- [[Incompatible Mode Solid Elements]] - internal displacement mode enrichment and static condensation for solid elements (status: current)
- [[Mixed Finite Element Formulations]] - multi-field formulations for incompressibility, constraints, and pressure-like variables (status: current)
- [[Nonlinear Finite Element Analysis]] - incremental solution of geometric, material, contact, and load nonlinearities (status: current)
- [[Continuum Mechanics Based Four-Node Shell Element]] - low-order shell element derived from continuum mechanics (status: current)
- [[Assumed Transverse Shear Strain Interpolation]] - shell locking remedy using a separately interpolated shear strain field (status: current)
- [[Total Lagrangian Shell Formulation]] - reference-configuration formulation for nonlinear shell response (status: current)
- [[MITC4 Shell Element]] - four-node quadrilateral shell element using mixed interpolation to avoid shear locking (status: current)
- [[MITC Shell Kinematics]] - director-vector shell kinematics for MITC-style degenerated continuum shells (status: current)
- [[Green-Lagrange Strain Linearization]] - nonlinear strain expansion for residual and tangent construction (status: current)
- [[Nonlinear Newmark-Beta Integration]] - Newton-iterated Newmark time integration for nonlinear FE dynamics (status: current)
- [[Dynamic Buckling Analysis]] - instability analysis under time-varying axial compression (status: current)
- [[Dynamic Instability Region]] - load-frequency region where dynamic buckling occurs (status: current)
- [[Geometric Stiffness Matrix]] - stress and geometry dependent stiffness contribution used in buckling analysis (status: current)
- [[Scordelis-Lo Shell Benchmark]] - cylindrical shell benchmark for shell element convergence (status: current)
- [[Basic Shell Mathematical Model]] - midsurface/director shell model underlying continuum shell finite elements (status: current)
- [[Shell Structure Asymptotic Behavior]] - thin-shell response classes under decreasing thickness (status: current)
- [[Shell Locking Phenomenon]] - thickness-dependent artificial stiffness in shell finite elements (status: current)
- [[Uniform Optimal Convergence]] - shell element convergence that remains optimal across thickness regimes (status: current)
- [[Shell Element Benchmark Testing]] - structured shell element performance testing across geometry, thickness, and meshes (status: current)
- [[Finite Element Heat Transfer and Field Problems]] - FE treatment of heat transfer, fields, flow, and coupled problems (status: current)
- [[Static Equilibrium Equation Solvers]] - direct, iterative, and nonlinear solvers for static FE equations (status: current)
- [[Direct Time Integration Methods]] - transient FE dynamics and first-order field integration (status: current)
- [[Finite Element Eigenproblem Solvers]] - modal and eigenvalue algorithms for FE matrices (status: current)
- [[Finite Element Program Implementation]] - software data flow for FE codes and STAP-style implementation (status: current)
---
## Entities
- [[Andrej Karpathy]] - AI researcher, creator of the LLM Wiki pattern, former Tesla AI director (status: developing)
- [[Claude SEO]] - Tier 4 Claude Code skill for SEO analysis (status: evergreen)
- [[Klaus-Jurgen Bathe]] - professor of mechanical engineering, author of [[Finite Element Procedures]], and co-author of [[A Continuum Mechanics Based Four-Node Shell]] (status: current)
- [[Eduardo N. Dvorkin]] - co-author of [[A Continuum Mechanics Based Four-Node Shell]] (status: current)
- [[Edita Dvorakova]] - co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]] (status: current)
- [[Borek Patzak]] - co-author of [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]] and OOFEM-related researcher (status: current)
- [[OOFEM]] - finite element code used for the MITC4 implementation (status: current)
- [[Hee Jun Lee]] - author of [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]] (status: current)
- [[Phill-Seung Lee]] - author of [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]] (status: current)
- [[Hyuk-Chun Noh]] - author of [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]] (status: current)
- [[Inha University]] - degree-granting institution for the dynamic shell buckling thesis (status: current)
- [[BLZPACK]] - Block Lanczos eigenvalue solver used in the dynamic buckling implementation (status: current)
- [[ABAQUS]] - commercial finite element software used for validation comparisons (status: current)
---
## Sources
- No active source pages.
---
## Questions
- [[How does the LLM Wiki pattern work]] - how the pattern works and why it outperforms RAG at human scale (status: developing)
---
## Comparisons
- [[Wiki vs RAG]] - when to use a wiki knowledge base versus RAG; verdict: wiki wins at under 1000 pages
---
## Decisions
- [[2026-04-14-community-cta-rollout]] - Skool community CTA footer added to 6 skill repos with per-tool frequency rules (status: active)
- [[2026-04-15-slides-and-release-session]] - Claude SEO v1.9.0 slides and GitHub release v1.9.0 with PDF asset (status: complete)
- [[2026-04-15-release-report-session]] - Claude SEO v1.9.0 Release Report PDF (status: complete)
- [[2026-04-14-claude-seo-v190-session]] - Claude SEO v1.9.0 Pro Hub Challenge integration (status: complete)
- [[Finite Element Procedures]] - 2014 textbook by [[Klaus-Jurgen Bathe]]; finite element theory, solvers, and implementation
- [[A Continuum Mechanics Based Four-Node Shell]] - Dvorkin and Bathe paper on a four-node shell element for nonlinear analysis
- [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]] - Dvorakova and Patzak paper on MITC4 implementation and Scordelis-Lo validation
- [[MITC Study Notes]] - local derivation notes for MITC shell kinematics, nonlinear strain linearization, and Newmark-beta dynamics
- [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]] - 2012 thesis on MITC4 shell dynamic buckling analysis
- [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]] - review paper on shell mathematical models, asymptotic behavior, locking, convergence, and benchmark testing
- [[Solid Element Notes]] - local notes on isoparametric linear solid element formulation, stiffness integration, and incompatible modes
---
## Domains
<!-- Add domain entries here after scaffold -->
- [[Computational Mechanics]] - finite element analysis, numerical methods, and engineering simulation
wiki/log.md
+48 -192
View File
@@ -25,202 +25,58 @@ Parse recent entries: `grep "^## \[" wiki/log.md | head -10`
---
## [2026-05-28] cleanup | Removed Claude + Obsidian ecosystem source artifacts
- Type: source cleanup
- Removed raw source: `.raw/claude-obsidian-ecosystem-research.md`
- Removed source summary: `wiki/sources/claude-obsidian-ecosystem-research.md`
- Removed generated pages: `wiki/comparisons/claude-obsidian-ecosystem.md`, `wiki/concepts/cherry-picks.md`, `wiki/entities/Ar9av-obsidian-wiki.md`, `wiki/entities/Nexus-claudesidian-mcp.md`, `wiki/entities/ballred-obsidian-claude-pkm.md`, `wiki/entities/rvk7895-llm-knowledge-bases.md`, `wiki/entities/kepano-obsidian-skills.md`, `wiki/entities/Claudian-YishenTu.md`
- Canvas check: no `.canvas` files referenced these source-generated pages, so no canvases were removed.
- Purpose: clear the old source-derived domain material before rebuilding the wiki around a different field.
## [2026-05-28] ingest | Solid Element Notes
- Source: `.raw/SolidElement/`
- Summary: [[Solid Element Notes]]
- Pages created: [[Solid Element Notes]], [[Isoparametric Linear Solid Elements]], [[Solid Element Shape Functions]], [[Solid Element Strain-Displacement Matrix]], [[Solid Element Stiffness Integration]], [[Incompatible Mode Solid Elements]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[Computational Mechanics]], [[Finite Element Method]], [[Isoparametric Finite Elements]], [[Displacement-Based Finite Element Formulation]], [[Mixed Finite Element Formulations]], [[dashboard]], [[getting-started]], [[Wiki Map]]
- Key insight: The notes add a 3D solid element formulation thread connecting natural-coordinate shape functions, Jacobian derivative mapping, `B^T D B` stiffness integration, and incompatible-mode enrichment.
## [2026-04-24] save | v1.6.0 public release notes (Teams, Karpathy-style)
- Type: release doc + visual assets
- Locations (new): `docs/releases/v1.6.0.md` (346 lines, 6 sections, Karpathy-style prose), `wiki/meta/dragonscale-mechanism-overview.svg` (4-mechanism diagram with shared .vault-meta/ gate), `wiki/meta/dragonscale-6-test-flow.svg` (validation timeline), `wiki/meta/dragonscale-frontier-graph.svg` (M4 candidate + 3 filed pages)
- Locations (modified): `wiki/meta/2026-04-24-v1.6.0-release-session.md` (cross-reference added pointing to public release notes)
- Scope: Teams approach. R1 (chair) wrote 3 original SVGs per SVG Diagram Style Guide. R2 (codex worker) drafted Karpathy-style release prose. R3 (chair) stitched SVGs, pivoted Wikipedia imagery to text links only (no binary vendoring per permission). R4 (codex verifier) returned ACCEPT WITH FIXES, 3 wording fixes on version narrative. R5 (chair) applied fixes, committed.
- Style: direct, short, signal-dense, lists over prose, no em dashes, no marketing terms. Verifier confirmed zero em-dashes and zero banned marketing language ('revolutionary', 'seamless', 'world-class', 'game-changing', 'unlock', 'transform').
- Distribution (all three destinations covered): (1) `docs/releases/v1.6.0.md` public-facing file (commit `85515bb`), (2) `wiki/meta/2026-04-24-v1.6.0-release-session.md` internal engineering record (cross-linked), (3) GitHub Release body (user to paste from docs/releases/v1.6.0.md when ready to `gh release create v1.6.0`).
- Wikipedia imagery: referenced as text link to `https://en.wikipedia.org/wiki/Dragon_curve` rather than hotlinked or vendored. Cleaner license-wise (no CC-BY-SA attribution needed) and no external dependency. The 3 original SVGs carry the visual load instead.
- PII scan post-write: `docs/releases/v1.6.0.md` + all three SVGs are clean. No `/home/` paths, no real emails, no tokens.
- Next recommended: user runs `gh release create v1.6.0 --notes-file docs/releases/v1.6.0.md` when ready to cut the public release. This also creates the annotated tag.
## [2026-05-28] ingest | On the Finite Element Analysis of Shell Structures
- Source: `.raw/쉘구조물의유한요소해석에대하여/`
- Summary: [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]]
- Pages created: [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]], [[Phill-Seung Lee]], [[Hyuk-Chun Noh]], [[Basic Shell Mathematical Model]], [[Shell Structure Asymptotic Behavior]], [[Shell Locking Phenomenon]], [[Uniform Optimal Convergence]], [[Shell Element Benchmark Testing]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[entities/_index]], [[Computational Mechanics]], [[Finite Element Method]], [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Mixed Finite Element Formulations]], [[MITC4 Shell Element]], [[Scordelis-Lo Shell Benchmark]], [[Klaus-Jurgen Bathe]], [[Wiki Map]]
- Key insight: The review connects shell mathematical models, thickness-dependent asymptotic behavior, locking, uniform optimal convergence, and benchmark design into one reliability framework for shell finite elements.
## [2026-04-24] save | DragonScale end-to-end validation pass (Teams, 6 tests)
- Type: validation + first real fold + first real autoresearch
- Tests executed (all green):
- T0 ollama pull `nomic-embed-text`: done (274MB, 15s wall)
- T1 M1 dry-run k=3 via codex: DRY-RUN OK, 8 children, no em-dashes
- T2 M2 real allocate: counter advanced 2 to 3, got `c-000002` (unassigned reservation; gap acceptable per spec)
- T3 M3 full tiling with model present: 41 pages scanned, 21 embedded, 20 correctly skipped (meta/excluded/embed-error), 0 errors at >=0.9, 15 pairs in 0.8-0.9 review band (top 0.8822 Compounding Knowledge vs LLM Wiki Pattern, a legitimate semantic neighbor), report at `wiki/meta/tiling-report-2026-04-24.md`
- T4 M1 commit via codex: first real fold committed, `wiki/folds/fold-k3-from-2026-04-23-to-2026-04-24-n8.md` (115 lines, 8 children, flat extractive). Flips the long-standing "no fold committed yet" status
- T6 M4 autoresearch no-topic via codex: selected "How does the LLM Wiki pattern work?" as candidate (score 1.7022, #3 after skipping top-1 source + top-2 self-reference); 6 web fetches (Karpathy gist, RAG paper arXiv 2005.11401, MemGPT arXiv 2310.08560, Obsidian docs); 3 new concept pages filed, each with Primary Sources
- Locations (new): `wiki/folds/fold-k3-from-2026-04-23-to-2026-04-24-n8.md`, `wiki/meta/tiling-report-2026-04-24.md`, `wiki/concepts/Persistent Wiki Artifact.md`, `wiki/concepts/Source-First Synthesis.md`, `wiki/concepts/Query-Time Retrieval.md`
- Locations (modified): `.vault-meta/address-counter.txt` (2 to 3), `wiki/index.md` (3 concept links), `wiki/concepts/_index.md` (3 concept links)
- Scope: six-test menu the user approved. Codex gpt-5.4 for T1/T4/T6 (sub-agent delegation); chair for T0/T2/T3 (one-shot shell) and all integration (index, log, hot, commit).
- Style: all new content uses colons or parens instead of em-dashes. Pre-existing em-dashes in index entries and wiki/concepts/_index.md left as-is (clean-room boundary; deferred to F-slice style pass).
- Tests still green: `make test` passes (74+ assertions).
- Integration: chair added the 3 new concepts to `wiki/index.md` and `wiki/concepts/_index.md` with colon-style descriptions so the fresh pages are discoverable. The cluster extends `[[How does the LLM Wiki pattern work?]]` and cross-references `[[LLM Wiki Pattern]]`.
- Next recommended slice: either (G) commit this test batch and declare v1.6.0 validated, or (H) run a second fold k=3 now that 8 newer entries exist above this one and close the hierarchical-fold-not-yet-supported loop in a future phase.
## [2026-05-28] ingest | Dynamic Buckling Analysis of Shell Structures using Finite Element Method
- Source: `.raw/유한요소해석법을이용한쉘구조물의동적좌굴해석/`
- Summary: [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]]
- Pages created: [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]], [[Hee Jun Lee]], [[Inha University]], [[BLZPACK]], [[ABAQUS]], [[Dynamic Buckling Analysis]], [[Dynamic Instability Region]], [[Geometric Stiffness Matrix]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[entities/_index]], [[Computational Mechanics]], [[MITC4 Shell Element]], [[Total Lagrangian Shell Formulation]], [[Finite Element Eigenproblem Solvers]], [[Direct Time Integration Methods]], [[Nonlinear Finite Element Analysis]], [[Finite Element Program Implementation]], [[Static Equilibrium Equation Solvers]], [[Wiki Map]]
- Key insight: The thesis connects MITC4 shell modeling to dynamic stability prediction through geometric stiffness, eigenvalue solvers, validation benchmarks, and load-frequency instability regions.
## [2026-04-24] save | v1.6.0 closeout (Teams, chair-led)
- Type: docs + release hygiene
- Locations (new): wiki/meta/2026-04-24-v1.6.0-release-session.md (release session summary, 346 lines), wiki/meta/boundary-frontier-2026-04-24.md (first M4 run artifact against this vault), docs/dragonscale-guide.md (user-facing DragonScale guide, 563 lines)
- Locations (modified): wiki/hot.md (tag-claim fix, Scripts line adds boundary-score, tests line adds test_boundary_score, push-line drift, tiling line-count, one em-dash), docs/install-guide.md (version 1.5.0 to 1.6.0, DragonScale callout expanded to all four mechanisms, "hierarchical log folds" corrected to "flat extractive log folds", points to docs/dragonscale-guide.md), README.md (DragonScale parenthetical expanded to all four mechanisms plus guide link)
- Scope: Teams approach, chair-led. Slice A (2 codex read-only explorers: closeout punch list + doc-surface map). Slice B (6 bounded writes: 4 chair, 2 codex workers, non-overlapping write scopes). Slice C (codex adversarial verifier, ACCEPT WITH FIXES). Slice D (fix pass + log entry + manual commit of docs + README).
- Verifier: C1 found 11 items across 6 files. All 11 applied. Flag typos `--allow-remote-ollama` and `--report PATH` corrected in release-session; boundary-frontier provenance corrected to `--top 7` to match default vs explicit top; hot.md tiling line-count claim stripped to avoid drift; hot.md "local tag only" corrected to "local commits only, no git tag"; install-guide log-fold wording corrected from "hierarchical" to "flat extractive"; dragonscale-guide rollback wording corrected (`.vault-meta/` is a shared gate across M2+M3+M4, not per-mechanism).
- Model: codex gpt-5.4 used throughout. User requested gpt-5.5; not reachable via codex CLI 0.123.0 / this account at the time. models_cache lists max gpt-5.4, and the API rejects gpt-5.5 with "does not exist or you do not have access". Existing config already has `service_tier = "fast"` and `sandbox_mode = "workspace-write"`, matching the "fast for chatgpt with permission of full access" intent.
- Tests: `make test` passes. test_allocate_address.sh (shell, 12 assertions), test_tiling_check.py (python, 18 assertions), test_boundary_score.py (python, 44 assertions). Zero ollama dependency.
- Tags: still no local v1.5.0 / v1.5.1 / v1.6.0 tags. User controls tag creation and push. Pre-existing tags unchanged (v1.1, v1.4.0 through v1.4.3).
- Deliberately NOT done: no real M1 fold committed; no M3 end-to-end run (needs `ollama pull nomic-embed-text`); pre-existing em-dashes in install-guide.md and README.md left untouched (clean-room boundary, not in write scope this slice); CLAUDE.md pre-existing uncommitted change left untouched.
- Next recommended slice: either (E) push to origin/main and create annotated tags v1.5.0, v1.5.1, v1.6.0 in landing order, or (F) dedicated style pass to scrub pre-existing em-dashes across install-guide.md, README.md, and any other wiki files flagged by a grep scan.
## [2026-05-28] ingest | MITC Study Notes
- Source: `.raw/MITC공부/`
- Summary: [[MITC Study Notes]]
- Pages created: [[MITC Study Notes]], [[MITC Shell Kinematics]], [[Green-Lagrange Strain Linearization]], [[Nonlinear Newmark-Beta Integration]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[Computational Mechanics]], [[MITC4 Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Total Lagrangian Shell Formulation]], [[Direct Time Integration Methods]], [[Nonlinear Finite Element Analysis]], [[Wiki Map]]
- Key insight: The study notes connect MITC shell kinematics to nonlinear FE solution by deriving director-vector displacement fields, Green-Lagrange strain linearization, tangent terms, and nonlinear Newmark-beta iteration.
## [2026-04-24] save | DragonScale Phase 4 — boundary-first autoresearch shipped (v1.6.0)
- Type: feature release
- Locations (new): scripts/boundary-score.py (with --top, --page, --json, stdout-only CLI), tests/test_boundary_score.py (40+ assertions)
- Locations (modified): skills/autoresearch/SKILL.md (new Topic Selection section A/B/C with helper-failure fallback), commands/autoresearch.md (no-topic candidate flow with agenda-control label), wiki/concepts/DragonScale Memory.md (v0.4: M4 flipped from NOT IMPLEMENTED to shipped; exact formula without recency floor; filename-stem disclosure; fence-handling qualifiers), CHANGELOG.md, .claude-plugin/{plugin,marketplace}.json (1.5.0 -> 1.6.0), Makefile (test-boundary target), wiki/hot.md, wiki/index.md, wiki/concepts/_index.md (status drift resolved).
- Scope: boundary-first autoresearch as opt-in Topic Selection mode. `/autoresearch` without a topic surfaces top-5 frontier pages; user picks/overrides/declines. Explicit helper-failure fallback to user-ask. Labeled "agenda control" throughout to match the spec's scope disclosure.
- Correctness: filename-stem resolution including folder-qualified `[[notes/Foo]]` -> Foo.md. Self-loops, unresolved targets, meta-targets, symlinks, and vault escapes all excluded. Code-fence parser handles backticks AND tildes with CommonMark length tracking (longer opening fence is not closed by shorter inner fence). Indented blocks intentionally not filtered (Obsidian bullet convention).
- Recency: exp(-days/30), no floor. Stale pages approach zero weight so they do not dominate frontier ranking.
- Review rounds: codex adversarial Phase 4 round 1 (10 items: 7 reject + 3 refine). Round 2 (7 accept + 3 still-reject: folder-qualified stem, docstring floor mention, hot.md historical drift). Round 3 (3 accept, PASS).
- Phase 3.6 (pre-Phase-4 hardening) already landed as v1.5.1: tiling --report VAULT_ROOT confinement, rollout baseline, AGENTS.md consistency, wiki-ingest .raw/ contradiction, install-guide version.
- All four DragonScale mechanisms now shipped and opt-in. 44 commits ahead of origin/main, no push.
## [2026-05-28] ingest | Four-Node Quadrilateral Shell Element MITC4
- Source: `.raw/FourNodeQuadrilateralShellElementMITC4/`
- Summary: [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]]
- Pages created: [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]], [[MITC4 Shell Element]], [[Scordelis-Lo Shell Benchmark]], [[Edita Dvorakova]], [[Borek Patzak]], [[OOFEM]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[entities/_index]], [[Computational Mechanics]], [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Finite Element Program Implementation]], [[A Continuum Mechanics Based Four-Node Shell]], [[Wiki Map]]
- Key insight: The MITC4 source turns the Dvorkin-Bathe four-node shell formulation into an implementation thread by using mixed interpolation to control shear locking, verifying OOFEM patch tests, and comparing Scordelis-Lo convergence.
## [2026-04-24] save | DragonScale Phase 3.5 — cross-phase hardening to v1.5.0
- Type: release hardening
- Locations (new): bin/setup-dragonscale.sh (opt-in installer), tests/test_allocate_address.sh, tests/test_tiling_check.py, Makefile, CHANGELOG.md
- Locations (modified): hooks/hooks.json (+.vault-meta/ staging), agents/wiki-ingest.md (single-writer rule for addresses), agents/wiki-lint.md (Mechanism 2+3 checks), skills/wiki-ingest/SKILL.md (aligned non-DragonScale wording), wiki/concepts/DragonScale Memory.md (M2 severity matches lint, M4 marked NOT IMPLEMENTED, seed page gets address c-000001), .claude-plugin/{plugin.json,marketplace.json} (1.4.2/1.4.3 → 1.5.0), README.md (11 skills + DragonScale callout), wiki/hot.md (refreshed for v1.5.0), .raw/.manifest.json (address_map now has DragonScale Memory.md → c-000001), .gitignore (.vault-meta/.tiling.lock + cache), .vault-meta/address-counter.txt (advanced to 2).
- Scope: resolve the 10 hold-ship items from the cross-phase audit. Add reproducible test harness (make test passes). Version-bump plugin.json and marketplace.json to 1.5.0. Create CHANGELOG.md. Refresh hot cache.
- Review rounds: codex 3.5a (5/5 accept on doc/agent fixes), codex final holistic (10/10 accept on audit items + 2 surgical regression fixes: wiki-ingest/wiki-lint non-DragonScale wording alignment, README skill count).
- Tests: `make test` runs 12 shell assertions (allocator) + 18 python assertions (tiling-check). All pass; no ollama dependency.
- Phase 3.5 complete. Repo state: 6 developer commits added this pass (f2e73c1, 2b49a0c, 8b28e48, 19ad7e4, 365f557, 2e7dd16). Total 39 commits ahead of origin/main. No push.
## [2026-05-28] ingest | A Continuum Mechanics Based Four-Node Shell
- Source: `.raw/AContinuumMechanicsBasedFourNodeShell/`
- Summary: [[A Continuum Mechanics Based Four-Node Shell]]
- Pages created: [[A Continuum Mechanics Based Four-Node Shell]], [[Eduardo N. Dvorkin]], [[Continuum Mechanics Based Four-Node Shell Element]], [[Assumed Transverse Shear Strain Interpolation]], [[Total Lagrangian Shell Formulation]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[entities/_index]], [[Computational Mechanics]], [[Klaus-Jurgen Bathe]], [[Finite Element Method]], [[Displacement-Based Finite Element Formulation]], [[Isoparametric Finite Elements]], [[Mixed Finite Element Formulations]], [[Nonlinear Finite Element Analysis]], [[Wiki Map]]
- Key insight: The paper shows how a low-order quadrilateral shell element can remain effective for thin and thick nonlinear shell analysis by combining a continuum-mechanics formulation, assumed transverse shear strain interpolation, and total Lagrangian kinematics.
## [2026-04-24] save | DragonScale Phase 3 — semantic tiling MVP
- Type: skill update + new script + threshold state
- Locations: scripts/tiling-check.py (485 lines), .vault-meta/tiling-thresholds.json (seed defaults), skills/wiki-lint/SKILL.md (109-line Semantic Tiling section + item #10 in checks), wiki/concepts/DragonScale Memory.md (Mechanism 3 cost framing clarified)
- Scope: opt-in embedding-based duplicate detection via ollama nomic-embed-text. Default bands error>=0.90, review>=0.80, explicitly documented as conservative seeds (not literature-backed interpolation). Calibration procedure documented, not automated.
- Security: default OLLAMA_URL locked to 127.0.0.1; non-localhost requires --allow-remote-ollama flag. Symlinks and vault-root escapes rejected before file reads (prevents data exfil).
- Correctness: cache keyed on sha256(model+body); orphan GC on save; model-drift auto-invalidation on load.
- Concurrency: flock(LOCK_EX) on .vault-meta/.tiling.lock; per-PID temp file for atomic writes.
- Scale: warn >500 pages; hard-fail exit 4 at >5000 pages.
- Exit codes: 0/2/3/4/10/11 distinctly surfaced in wiki-lint wiring (not collapsed into "unknown").
- Review rounds: 4 codex exec adversarial passes covering security, cache correctness, feature gate, inclusion logic, scale, threshold honesty, concurrency, exit codes, model drift, terminology coupling.
Round 1: 10 items -> 7 reject + 3 refine.
Round 2: 6 accept + 4 still-reject (symlink ordering, prose sync, exit-code wiring, terminology in checklist + "no API cost" claim).
Round 3: 3 accept + 1 still-reject (cost-framing phrasing).
Round 4: accept.
- Final verdict: 10/10 accept.
- Phase 3 complete. All three DragonScale mechanisms that were in-scope for the initial spec are now shipped as opt-in features. Mechanism 4 (boundary-first autoresearch) was flagged as agenda-control out-of-scope per the v0.2 scope boundary; may or may not ship as a future phase.
## [2026-05-28] cleanup | Trimmed wiki to finite element scope
- Type: scope cleanup
- Removed non-finite-element wiki content pages, old canvases, old fold pages, old question/comparison notes, and old release/audit/session artifacts under `wiki/`.
- Preserved wiki operational files: [[index]], [[hot]], [[log]], [[overview]], all `_index.md` files, [[dashboard]], [[Wiki Map]], [[getting-started]], and `wiki/references/`.
- Trimmed this log to 2026-05-28 entries only.
- Current scope: [[Finite Element Procedures]] and [[Computational Mechanics]].
## [2026-04-23] save | DragonScale Phase 2 — deterministic page addresses MVP
- Type: skill update + new script
- Locations: scripts/allocate-address.sh, skills/wiki-ingest/SKILL.md (Address Assignment section), skills/wiki-lint/SKILL.md (Address Validation section), wiki/concepts/DragonScale Memory.md (Mechanism 2 rewritten v0.2→v0.3), .vault-meta/address-counter.txt, .raw/.manifest.json (new)
- Scope: MVP address format `c-NNNNNN` (creation-order counter, zero-padded 6 digits). Rollout baseline 2026-04-23. Legacy pages exempt until deliberate backfill (future `l-` prefix). No content hash, no fold-ancestry encoding in the MVP (both deferred).
- Concurrency: atomic allocation via flock-guarded Bash helper. Counter recovery from max observed `c-` address, never silent reset to 1.
- Lint: post-rollout pages without address are errors; legacy pages without address are informational. Optional `.vault-meta/legacy-pages.txt` manifest grandfathers pages with missing/wrong `created:` metadata.
- Re-ingest idempotency: `.raw/.manifest.json` `address_map` preserves path→address mapping across re-ingests and renames.
- Naming: mechanism renamed from "content-addressable paths" to "deterministic page addresses" (the MVP is a counter, not a content hash; the old name was overclaim).
- Review rounds: 2 codex exec adversarial passes. Round 1: 8 rejects covering counter mutation, race conditions, uniqueness atomicity, missing-file recovery, terminology drift, silent regression path, legacy classification, re-ingest idempotency. Round 2: 7 accept + 1 reject (manifest.json absent). Round 3 (item 8 only): accept after creating `.raw/.manifest.json`.
- Final verdict: 8/8 accept.
- Phase 2 complete. Phase 3 (semantic tiling lint) gated on human approval.
## [2026-04-23] save | DragonScale Phase 1 — wiki-fold skill shipped
- Type: skill
- Location: skills/wiki-fold/SKILL.md, skills/wiki-fold/references/fold-template.md
- Scope: flat extractive fold over raw wiki/log.md entries. Dry-run default via Bash stdout (no Write tool, avoids PostToolUse hook residue). Structural idempotency via deterministic fold_id. Duplicate-range detection. Fold-of-folds explicitly out of scope.
- Review rounds: 3 codex exec adversarial passes. Round 1: 1 refine + 6 reject across 7 items (allowed-tools, hook-mutation risk, idempotency claim, dry-run faithfulness, children structure, Mechanism 1 coverage, auto-commit conflict). Round 2: 6 accept + 1 reject (25/26 count inversion). Round 3 (item 4 only): accept.
- Final verdict: 7/7 accept.
- Dry-run artifact: /tmp/wiki-fold-dry-run-v2.md (not committed). fold_id: fold-k3-from-2026-04-10-to-2026-04-23-n8.
- Phase 1 complete. Phase 2 (content-addressable paths) gated on human approval.
## [2026-04-23] save | DragonScale Memory v0.2 — post-adversarial-review
- Type: concept revision
- Location: wiki/concepts/DragonScale Memory.md
- Review: codex exec adversarial review rejected all 7 load-bearing claims in v0.1
- Changes: weakened LSM analogy, removed strong prompt-cache claim, replaced 0.85 threshold with calibration procedure, justified 2^k as MVP convenience, acknowledged scope-boundary leak for boundary-first autoresearch, added Operational Policies section (retention/tombstones/versioning/conflict/concurrency/provenance/ACL), tagged claims as [sourced]/[derived]/[conjecture], narrowed tagging scope per re-review
- Re-review result: 7/7 accepted (after one surgical fix on tagging-scope language)
- Phase 0 complete. Phase 1 (wiki-fold skill) gated on human approval.
## [2026-04-23] save | DragonScale Memory — Phase 0 design doc (proposed)
- Type: concept
- Location: wiki/concepts/DragonScale Memory.md
- From: brainstorming session on applying Heighway dragon curve properties to LLM wiki memory architecture
- Scope: memory-layer only, NOT agent reasoning. Four mechanisms: (1) fold operator (LSM-style exponential compaction at 2^k log entries), (2) content-addressable page paths for prompt-cache stability, (3) semantic tiling lint (embedding-based dedup, 0.85 cosine threshold), (4) boundary-first autoresearch scoring
- Status: proposed. Phase 0 pending codex adversarial review. Phase 1+ (fold skill, address anchors, tiling lint, boundary score) gated on review pass.
- Primary sources verified: Dragon curve (Wikipedia, boundary dim 1.523627086), Regular paperfolding sequence (OEIS A014577), LSM trees (arXiv 2504.17178, LevelDB 10x level ratio), MemGPT (arXiv 2310.08560), Anthropic prompt caching docs (5min/1hr TTL, 20-block lookback)
- Links updated: wiki/concepts/_index.md, wiki/index.md
## [2026-04-15] save | Claude SEO v1.9.0 Slides and GitHub Release
- Type: session
- Location: wiki/meta/2026-04-15-slides-and-release-session.md
- From: built 15-slide HTML presentation deck (v190.html), fixed hardcoded path in release_report.py, pushed 68 files to GitHub, tagged v1.9.0, created GitHub release with PDF asset
- Key lessons: Path.home() not hardcoded paths, git pull --rebase before big pushes, Chrome blocks file:// cross-origin images, .claude/ always in .gitignore
- Release: https://github.com/AgriciDaniel/claude-seo/releases/tag/v1.9.0
## [2026-04-15] save | Claude SEO v1.9.0 Release Report — PDF Complete
- Type: session
- Location: wiki/meta/2026-04-15-release-report-session.md
- From: full session completing the v1.9.0 PDF release report. Dark theme, 13 pages, 1.53 MB. Fixed logo (double-space filename), empty spaces, page-break orphans, file:// URL encoding.
- Key fixes: `urllib.parse.quote()` for file:// URIs; `display:table-cell` is atomic in WeasyPrint (no page-break); fixed `height:297mm` causes empty space; replaced orphan tables with paragraphs
- Challenge v2 added: keyword LEADS, $600 prize pool, deadline April 28
- Output: `~/Desktop/Claude-SEO-v1.9.0-Release-Report.pdf`
## [2026-04-14] save | Claude SEO v1.9.0 — Pro Hub Challenge Integration Session
- Type: session + 4 concept pages + 1 entity page
- Location: wiki/meta/2026-04-14-claude-seo-v190-session.md
- From: full v1.9.0 implementation session — reviewed 5 community submissions, integrated 4 new skills (seo-cluster, seo-sxo, seo-drift, seo-ecommerce), enhanced seo-hreflang, added DataForSEO cost guardrails
- Pages created: [[2026-04-14-claude-seo-v190-session]], [[Claude SEO]], [[Pro Hub Challenge]], [[Semantic Topic Clustering]], [[Search Experience Optimization]], [[SEO Drift Monitoring]]
- Review rounds: 4 (code review x3 + cybersecurity audit). Score: 87 → 93 → 97 → 85 security
- Key learnings: always verify subagent output (40-line count error caught), insertion-point bugs caught by max-effort plan review, pre-existing security debt identified (10 of 15 findings)
## [2026-04-14] save | SVG Diagram Style Guide
- Type: concept
- Location: wiki/concepts/SVG Diagram Style Guide.md
- From: extracted design tokens from 17 production SVGs in claude-ads/assets/diagrams/
- Covers: colors, typography, layout primitives, card patterns, arrow connectors, numbered circles, file naming
## [2026-04-14] save | Community CTA Footer Rollout
- Type: decision
- Location: wiki/meta/2026-04-14-community-cta-rollout.md
- From: session adding Skool community footer to 6 skill repos (claude-ads, claude-seo, claude-obsidian, claude-blog, banana-claude, claude-cybersecurity)
- Key insight: frequency calibration per tool type; single-point orchestrator instruction pattern
## [2026-04-10] save | Backlink Empire - Blog Posts, Karpathy Gist, GitHub Cross-Linking
- Type: session
- Location: wiki/meta/2026-04-10-backlink-empire-session.md
- From: full session covering blog creation (claude-obsidian + claude-canvas), Karpathy gist comment, 26 GitHub README updates with Author/community/backlink sections, homepage URLs on 10 repos, topics on 25 repos, rankenstein.pro backlinks on 5 SEO repos
- Blog posts: agricidaniel.com/blog/claude-obsidian-ai-second-brain, agricidaniel.com/blog/claude-canvas-ai-visual-production
- Impact: ~87 new backlinks from DA 96 github.com, 6 rankenstein.pro backlinks, 25 Skool community links
## [2026-04-08] save | claude-obsidian v1.4 Release Session
- Type: session
- Location: wiki/meta/claude-obsidian-v1.4-release-session.md
- From: full release cycle covering v1.1 (URL/vision/delta tracking, 3 new skills), v1.4.0 (audit response, multi-agent compat, Bases dashboard, em dash scrub, security history rewrite), and v1.4.1 (plugin install command hotfix)
- Key lessons: plugin install is 2-step (marketplace add then install), allowed-tools is not valid frontmatter, Bases uses filters/views/formulas not Dataview syntax, hook context does not survive compaction, git filter-repo needs 2 passes for full scrub
## [2026-04-08] ingest | Claude + Obsidian Ecosystem Research
- Type: research ingest
- Source: `.raw/claude-obsidian-ecosystem-research.md`
- Queries: 6 parallel web searches + 12 repo deep-reads
- Pages created: [[claude-obsidian-ecosystem]], [[cherry-picks]], [[claude-obsidian-ecosystem-research]], [[Ar9av-obsidian-wiki]], [[Nexus-claudesidian-mcp]], [[ballred-obsidian-claude-pkm]], [[rvk7895-llm-knowledge-bases]], [[kepano-obsidian-skills]], [[Claudian-YishenTu]]
- Key finding: 16+ active Claude+Obsidian projects; 13 cherry-pick features identified for v1.3.0+
- Top gap confirmed: no delta tracking, no URL ingestion, no auto-commit
## [2026-04-07] session | Full Audit, System Setup & Plugin Installation
- Type: session
- Location: wiki/meta/full-audit-and-system-setup-session.md
- From: 12-area repo audit, 3 fixes, plugin installed to local system, folder renamed
## [2026-04-07] session | claude-obsidian v1.2.0 Release Session
- Type: session
- Location: wiki/meta/claude-obsidian-v1.2.0-release-session.md
- From: full build session — v1.2.0 plan execution, cosmic-brain→claude-obsidian rename, legal/security audit, branded GIFs, PDF install guide, dual GitHub repos
- Source: `.raw/` (first ingest)
- Pages updated: [[index]], [[log]], [[hot]], [[overview]]
- Key insight: The wiki pattern turns ephemeral AI chat into compounding knowledge — one user dropped token usage by 95%.
## [2026-04-07] setup | Vault initialized
- Plugin: claude-obsidian v1.1.0
- Structure: seed files + first ingest complete
- Skills: wiki, wiki-ingest, wiki-query, wiki-lint, save, autoresearch
## [2026-05-28] ingest | Finite Element Procedures
- Source: `.raw/FiniteElementProcedures/`
- Summary: [[Finite Element Procedures]]
- Pages created: [[Finite Element Procedures]], [[Klaus-Jurgen Bathe]], [[Computational Mechanics]], [[Finite Element Method]], [[Engineering Mathematical Models]], [[Displacement-Based Finite Element Formulation]], [[Isoparametric Finite Elements]], [[Mixed Finite Element Formulations]], [[Nonlinear Finite Element Analysis]], [[Finite Element Heat Transfer and Field Problems]], [[Static Equilibrium Equation Solvers]], [[Direct Time Integration Methods]], [[Finite Element Eigenproblem Solvers]], [[Finite Element Program Implementation]]
- Pages updated: [[index]], [[overview]], [[hot]], [[sources/_index]], [[concepts/_index]], [[entities/_index]], [[domains/_index]], [[log]]
- Key insight: The source frames finite element analysis as a modeling workflow that connects physical idealization, element formulation, algebraic solvers, and program implementation.
wiki/meta/2026-04-10-backlink-empire-session.md
-95
View File
@@ -1,95 +0,0 @@
---
type: session
title: "Backlink Empire - Blog Posts, Karpathy Gist, GitHub Cross-Linking"
created: 2026-04-10
updated: 2026-04-10
tags:
- session
- backlinks
- seo
- github
- blog
- rankenstein
status: complete
related:
- "[[Claude Obsidian]]"
- "[[Claude Canvas]]"
- "[[Rankenstein]]"
- "[[Karpathy LLM Wiki Pattern]]"
decision_date: 2026-04-10
---
## What Was Done
### Blog Posts Created
Two blog posts written, deployed to Vercel, and submitted to Google Indexing API + Bing IndexNow:
1. **claude-obsidian-ai-second-brain** - "I Turned Obsidian Into a Self-Organizing AI Brain"
- Focus keyword: "obsidian ai second brain"
- ~2,800 words, 5 repo images/GIFs, 3 SVG charts, 8 sourced statistics
- Images from `wiki/meta/` in the claude-obsidian repo (graph view, wiki map, welcome canvas GIF)
- Live: agricidaniel.com/blog/claude-obsidian-ai-second-brain
2. **claude-canvas-ai-visual-production** - "Claude Code Just Turned Obsidian Canvas Into an AI Design Studio"
- Focus keyword: "obsidian canvas ai"
- ~2,500 words, 5 screenshots from repo, 2 SVG charts, 7 sourced statistics
- Images from `assets/screenshots/` in the claude-canvas repo
- Live: agricidaniel.com/blog/claude-canvas-ai-visual-production
### Karpathy Gist Comment
Comment posted on Andrej Karpathy's LLM Wiki gist (gist ID: 442a6bf555914893e9891c11519de94f). Links claude-obsidian (358 stars), claude-canvas, and the blog post. Highlights hot cache, contradiction flagging, 8-category lint, and autonomous research loops as differentiators.
### GitHub Backlink Empire (26 Repos Updated)
**Phase 1 - API updates (no README changes):**
- Set homepage URLs on 10 repos (on-page-seo, Keywordo-kun, claude-youtube, marketing-skill-pack, google-maps-scraper, claude-repurpose, claude-gif, claude-avatar, rankenstein-pro-latest, claude-canvas)
- Set topics/tags on 25 repos (grouped by category: SEO, content, marketing, obsidian, media, dev tools, n8n)
**Phase 2-5 - README updates:**
- Added standardized Author section to 25 repos with links to:
- agricidaniel.com/about
- agricidaniel.com/blog
- skool.com/ai-marketing-hub
- youtube.com/@AgriciDaniel
- github.com/AgriciDaniel
**Rankenstein.pro backlinks (5 SEO-relevant repos only):**
- claude-seo: "Publishing Pipeline" section
- claude-blog: "Publishing Platform" section
- on-page-seo: blockquote before Author
- Keywordo-kun: blockquote before Author
- marketing-skill-pack: mentioned in Author context
### Verification Results
64/65 checks passed. 1 minor note: claude-obsidian uses footer-style attribution instead of formal `## Author` heading (intentional - already had custom attribution).
## Key Decisions
- **rankenstein.pro placement**: Only on SEO-relevant repos (5 of 26). Not spammed across video/image/dev tools. Keeps it natural.
- **Karpathy gist tone**: Technical, value-first. Led with the implementation, not marketing. Matched the collaborative tone of the comment thread.
- **Blog keyword strategy**: "obsidian ai second brain" (trending, moderate competition) and "obsidian canvas ai" (low competition, growing query). Both exploit competitor gaps - no existing article covers a specific tool in depth.
- **Cover images**: Used real repo assets (pixel-art covers, screenshots, GIFs) rather than stock photos. Converts better and is more authentic.
## Numbers
- ~87 new backlinks from github.com (DA 96) to agricidaniel.com
- ~6 backlinks to rankenstein.pro
- ~25 backlinks to skool.com/ai-marketing-hub
- 22 total pages in sitemap (was 20 at session start)
- 15 total blog posts (was 13)
## Workflow for Future Blog Posts
This session established a repeatable workflow:
1. Explore repo thoroughly (features, images, stats)
2. Keyword research + competitor analysis via web search
3. Write blog JSON with HTML content, SVG charts, repo images
4. Add to blogPosts.ts, sitemap.xml, llms.txt
5. Build + prerender + deploy to Vercel
6. Submit to Google Indexing API + Bing IndexNow
7. Set repo homepage to blog URL
8. Add blog backlink to repo README
9. Update README with Author/community section
wiki/meta/2026-04-14-claude-seo-v190-session.md
-77
View File
@@ -1,77 +0,0 @@
---
type: meta
title: "Claude SEO v1.9.0 — Pro Hub Challenge Integration Session"
created: 2026-04-14
updated: 2026-04-14
tags:
- session
- claude-seo
- v1.9.0
- pro-hub-challenge
- release
status: complete
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
- "[[Semantic Topic Clustering]]"
- "[[Search Experience Optimization]]"
- "[[SEO Drift Monitoring]]"
- "[[E-commerce SEO]]"
---
# Claude SEO v1.9.0 — Pro Hub Challenge Integration
**Date**: 2026-04-14
**Duration**: Extended session (~4 hours)
**Scope**: Integrate 5 community submissions from the AI Marketing Hub Pro Hub Challenge into claude-seo
## What Was Done
### Community Submissions Integrated
| Contributor | Submission | Integrated As |
|------------|------------|--------------|
| **Lutfiya Miller** (Winner) | Semantic Cluster Engine | `seo-cluster` — SERP overlap clustering, hub-spoke architecture, interactive visualization |
| **Florian Schmitz** | SXO Skill | `seo-sxo` — page-type mismatch detection, SERP-to-user-story, persona scoring |
| **Dan Colta** | SEO Drift Monitor | `seo-drift` — baseline/diff/track with 17 comparison rules, SQLite persistence |
| **Chris Muller** | Multi-lingual SEO | `seo-hreflang` enhancements — cultural profiles (DACH, FR, ES, JA), locale formats, content parity audit |
| **Matej Marjanovic** | E-commerce + DataForSEO Cost Config | `seo-ecommerce` + cost guardrails with approval workflow |
### Numbers
- **Before**: 19 skills, 13 agents, 23 scripts (v1.8.2)
- **After**: 23 skills, 17 agents, 30 scripts (v1.9.0)
- **New files created**: 30
- **Existing files modified**: 31
- **Total lines added**: ~5,500
### Architecture Decisions
1. **SEO parts only** — blog-specific features (translation, multilingual pipeline, character images) stay for claude-blog
2. **Full integration with optional execution** — cluster skill outputs content briefs when claude-blog isn't detected, full execution when it is
3. **Security-hardened drift scripts** — original had SSRF bypass via curl fallback. Completely rewritten using only fetch_page.py
4. **Cost guardrails** — threshold-based approval, daily limits, file locking, audit trail on reset
## Review Process (4 rounds)
| Round | Type | Score | Issues Found |
|-------|------|-------|-------------|
| 1 | superpowers:code-reviewer (3 agents) | 87/100 | 6 critical (step numbering, SSRF fallback, install.ps1, counts, CHANGELOG, README) |
| 2 | superpowers:code-reviewer (3 agents) | 89/100 → 93/100 after fixes | 8 important (drift history routing, marketplace.json, audit math, AGENTS.md, CONTRIBUTING) |
| 3 | superpowers:code-reviewer (3 agents) | 97/100 | 5 suggestions only (all pre-existing) |
| 4 | /cybersecurity (8 agents) | 77/100 → 85/100 after fixes | H3: cost bypass, M4: XSS, M3: CI, M5: locking, L5: pyproject |
### Security Findings & Fixes
- **XSS in cluster-map.html** — `truncate()` wasn't wrapped in `escapeHtml()`. Fixed.
- **Cost guardrail bypass** — `reset` + unknown endpoint = unlimited spend. Fixed: reset requires `--confirm` + audit trail, unknown endpoints return `needs_approval`.
- **File locking** — cost ledger had no locking for parallel agents. Fixed with fcntl.
- **Pre-existing (deferred)**: validate_url DNS rebinding, install script injection, OAuth file permissions, no pip lockfile
## Key Learnings
1. **Agent output verification is essential** — subagents got seo/SKILL.md line count wrong by 40 lines, miscounted skills (25 vs 23), and would have placed CONTRIBUTING.md section in wrong location (orphaning subsections)
2. **Security audits find real bugs** — the XSS and cost guardrail bypass were genuine issues that static review missed
3. **Pre-existing vs new** — of 15 security findings, only 5 were introduced by v1.9.0. The codebase has technical debt from earlier versions
4. **Plan review catches insertion-point bugs** — the max-effort plan review found 2 bugs (CONTRIBUTING.md section placement, README command ordering) before they were executed
## Files for Reference
- Plan: `~/.claude/plans/smooth-popping-pebble.md`
- CHANGELOG: v1.9.0 entry in `~/Desktop/Claude-SEO/CHANGELOG.md`
- Contributors: `~/Desktop/Claude-SEO/CONTRIBUTORS.md`
wiki/meta/2026-04-14-community-cta-rollout.md
-58
View File
@@ -1,58 +0,0 @@
---
type: decision
title: "Community CTA Footer Rollout"
created: 2026-04-14
updated: 2026-04-14
decision_date: 2026-04-14
status: active
tags:
- marketing
- skool
- community
- growth
related:
- "[[index]]"
---
# Community CTA Footer Rollout
AI Marketing Hub Skool community links (free + pro) added as a footer to 6 Claude Code skill repos. The footer appears after major deliverables, never during mid-workflow or on quick utilities.
## The Footer
```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Built by agricidaniel - Join the AI Marketing Hub community
Free -> https://www.skool.com/ai-marketing-hub
Pro -> https://www.skool.com/ai-marketing-hub-pro
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
## Implementation Pattern
Single-point instruction in each repo's orchestrator SKILL.md. One section controls the footer text, show list, and skip list. No duplication across sub-skills.
## Per-Repo Frequency Calibration
| Repo | Triggers | Rationale |
|------|----------|-----------|
| claude-ads | 12 commands | Audits, reports, analyses (each is a session-level event) |
| claude-seo | 12 commands | Audits, technical, content (same pattern as ads) |
| claude-obsidian | 3 operations | Only scaffold, lint, autoresearch (high-frequency tool, conservative) |
| claude-blog | 8 commands | Write, rewrite, audit, analyze, brief, strategy, calendar, geo. Explicit guard: never in generated blog content/HTML |
| banana-claude | 4 commands | Image generate, edit, batch (skip chat, inspire, config) |
| claude-cybersecurity | All audits | Single-purpose tool, every completed report gets it |
## Design Principles
1. Free link listed first. Pro framed as "support the creator," not a gate.
2. Footer appears only after value is delivered, never before or during.
3. High-frequency tools (obsidian, banana chat) get fewer triggers to avoid spam.
4. Content-producing tools (blog) explicitly exclude CTA from generated output.
5. Single source of truth per repo. Update one section to change everything.
## Future Considerations
- Add "once per conversation" cap if power users report repetition across back-to-back commands.
- Track conversion rate. If zero joins after months, experiment with wording.
- Forks will strip the CTA. That is fine and expected under MIT license.
wiki/meta/2026-04-15-release-report-session.md
-61
View File
@@ -1,61 +0,0 @@
---
type: meta
title: "Claude SEO v1.9.0 Release Report Session"
updated: 2026-04-15
tags:
- meta
- session
- claude-seo
- pdf
- weasyprint
status: complete
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
- "[[2026-04-14-claude-seo-v190-session]]"
---
# Claude SEO v1.9.0 Release Report Session
Date: 2026-04-15 | Output: `~/Desktop/Claude-SEO-v1.9.0-Release-Report.pdf`
## What Was Built
13-page dark-theme PDF release report for Claude SEO v1.9.0. Generated via `scripts/release_report.py` using WeasyPrint + matplotlib. Covers: Pro Hub Challenge contributions, architecture evolution, review score progression, security audit findings, DataForSEO cost guardrails, and Challenge v2 announcement.
**Stats**: 13 pages, 1.53 MB, 4 charts, 7 screenshots embedded, logo visible on title page.
**Brand**: Space Grotesk font, `#0A0A0A` background, `#E07850` accent (rust-orange), `#111111` cards, `#2D2D2D` borders. Matches SVG Diagram Style Guide.
## Bugs Fixed
| Bug | Root Cause | Fix |
|-----|-----------|-----|
| Logo not rendering | Filename has double space: "AI MArketing hub pro logo with white text.png" | Corrected path in `generate_report()` |
| `file://` images not loading | Spaces in paths not URL-encoded | Added `_file_url()` helper with `urllib.parse.quote()` |
| Review checker false WARNs | Checked URL-encoded paths against filesystem | `unquote()` before `Path.exists()` |
| Title page empty bottom half | Fixed `height:297mm` + sparse content | Removed fixed height, added "In This Report" card |
| Contributor card page-break orphans | `display:table-cell` is atomic in WeasyPrint | Replaced two-column layout with stacked blocks |
| Architecture scripts table orphaned | 7-row table split across pages | Replaced table with paragraph |
| Security highlight box orphaned | Orphaned after large table | Merged text into intro paragraph |
| Chart page mostly empty | Chart too small relative to page | Increased figsize height, moved chart first in section |
## WeasyPrint PDF Lessons
1. **`file://` URIs must be URL-encoded** — spaces become `%20`. Use `urllib.parse.quote(path, safe="/:@")`. When reviewing paths extracted from HTML, use `unquote()` before `Path.exists()`.
2. **`display:table-cell` is atomic** — WeasyPrint cannot break a table-cell across pages. For content that might span pages (contributor cards, multi-row content), use stacked block elements (`<p>` + `<ul>`) instead of two-column table layouts.
3. **Fixed height causes empty space** — `height: 297mm` on a div with sparse content leaves blank below. Use auto height + generous padding instead.
4. **Tables that overflow: replace with paragraphs** — if a table consistently orphans its last rows, a `<p>` with inline `<code>` spans is more reliable.
5. **Chart figsize controls page fill** — matplotlib figsize directly affects how much of the page the chart occupies. Increase height to fill empty space after a chart.
6. **`max-height: 165mm` on `.chart-container img`** — good default for charts on their own section page.
7. **Check filenames carefully** — "AI MArketing hub pro logo with white text.png" has a double space between "hub" and "pro". `Path.exists()` is the fastest way to catch this.
## Pro Hub Challenge v2 (April)
Added to the report's "What's Next" section. Details:
- Keyword: **LEADS**
- Prizes: $400 (1st) + $200 (2nd) in Claude Credits
- Deadline: April 28, 2026
- Scope: anything touching lead generation — Claude Code skills, n8n workflows, MCP servers, scrapers, dashboards, pipelines
- Rules: GitHub repo or .zip + 1-2 min demo video, must be functional, solo or team welcome
- Previous winner: Lutfiya Miller (seo-cluster, integrated in v1.9.0)
wiki/meta/2026-04-15-slides-and-release-session.md
-79
View File
@@ -1,79 +0,0 @@
---
type: meta
title: "Claude SEO v1.9.0 Slides and GitHub Release Session"
updated: 2026-04-15
tags:
- meta
- session
- claude-seo
- github
- slides
status: complete
related:
- "[[Claude SEO]]"
- "[[Pro Hub Challenge]]"
- "[[2026-04-14-claude-seo-v190-session]]"
- "[[2026-04-15-release-report-session]]"
---
# Claude SEO v1.9.0 Slides and GitHub Release Session
Date: 2026-04-15 | Outputs: `claude-seo-slides/v190.html`, GitHub release v1.9.0
## What Was Built
### HTML Slide Deck (claude-seo-slides/v190.html)
15-slide community presentation for the v1.9.0 release. Scroll-snap HTML, no external library. Matches the existing v1.7.2 dark-theme brand exactly.
**Tech pattern:**
- `scroll-snap-type: y mandatory` on `html`, each slide `min-height:100vh` + `scroll-snap-align: start`
- `IntersectionObserver` per slide to update progress bar and nav dots
- Keyboard: ArrowDown/Right/Space to advance, ArrowUp/Left to go back
- `file:///` absolute paths for local screenshots with `onerror` fallback handlers
**Brand:** `#0A0A0A` bg, `#E07850` coral accent, Space Grotesk headings, IBM Plex Mono body. `.claude/`, `.superpowers/` added to `.gitignore` before push.
**Slide structure (15 slides):**
| # | Title | Key Content |
|---|-------|-------------|
| 01 | Title | 23 skills, 5 contributors, 4 new skills, 30 scripts |
| 02 | Executive Summary | 8 metric cards, community wins, technical wins |
| 03 | The Challenge | 3 cards, full 8-stage timeline table |
| 04 | Community Posts | Announcement + winner screenshots (local file paths) |
| 05 | Contributors | All 6, with Winner/Proficient/Reviewed badges |
| 06 | seo-cluster | Lutfiya Miller, features, screenshot, integration notes |
| 07 | seo-sxo | Florian Schmitz, detection example, screenshot |
| 08 | seo-drift | Dan Colta, flow diagram, features, screenshot |
| 09 | seo-ecommerce | Matej Marjanovic, cost approval box, screenshot |
| 10 | seo-hreflang | Chris Muller, cultural profiles table, screenshot |
| 11 | Architecture Evolution | Before/after counts, 7 new scripts list |
| 12 | Review Process | Score timeline 87→93→97→85, findings table per round |
| 13 | Security Audit | 85/100, detailed fixes table |
| 14 | DataForSEO Guardrails | Bypass chain, before/after code snippet, fcntl |
| 15 | What's Next | v1.9.1 H1/H2/M1 deferred items, Challenge v2 LEADS |
**Screenshot paths note:** `claude-seo-slides/v190.html` contains 7 absolute `file://` home paths for community post screenshots. Not sensitive, but not portable. `onerror` handlers show placeholder text when images fail. Works in Firefox; Chrome blocks cross-origin `file://` image requests.
### GitHub Release v1.9.0
**Steps taken:**
1. Fixed `SCREENSHOTS_DIR` hardcoded path in `scripts/release_report.py`: replaced the old absolute home Downloads path with `Path.home() / "Downloads" / "..."` (Path was already imported).
2. Added `.claude/` and `.superpowers/` to `.gitignore`.
3. Staged 68 files (31 modified, 37 new), committed as `feat: v1.9.0 Pro Hub Challenge community integration`.
4. Remote had 1 commit ahead ("Remove blog links from README") — resolved with `git pull --rebase`.
5. Tagged `v1.9.0` on HEAD, pushed tag.
6. Created GitHub release via `gh release create v1.9.0` with PDF attached (`Claude-SEO-v1.9.0-Release-Report.pdf`). No HTML slides attached as release asset.
**Release URL:** https://github.com/AgriciDaniel/claude-seo/releases/tag/v1.9.0
**Commit stats:** 68 files, 9,662 insertions, 51 deletions.
## Key Lessons
1. **`Path.home()` for user-relative paths in scripts** — never hardcode `/home/username/...`. Use `Path.home() / "..."` or `os.path.expanduser("~")`. Catches before push with a simple `grep -rn "/home/"`.
2. **Always `git pull --rebase` before pushing a big local commit** — even on solo repos with active GitHub Actions or web edits. Avoids a merge commit cluttering the history.
3. **`gh release create` attaches assets directly** — pass file path as positional argument. Only attach what users actually need to download (PDF), not presentation assets (HTML) that live in the repo.
4. **`.claude/` and `.superpowers/` should always be in `.gitignore`** — they hold project-specific Claude Code permissions and plugin state. Not credentials, but not repo content either.
5. **Chrome blocks `file://` cross-origin image requests** — HTML files opened as `file://` cannot load images from other `file://` paths in Chrome. Firefox allows it. For portable local HTML with images, use `python3 -m http.server` or embed images as base64 data URIs.
wiki/meta/2026-04-24-v1.6.0-release-session.md
-348
View File
@@ -1,348 +0,0 @@
---
type: meta
title: "2026-04-24 v1.6.0 Release Session"
created: 2026-04-24
updated: 2026-04-24
tags:
- meta
- session
- release
- dragonscale
status: evergreen
related:
- "[[log]]"
- "[[hot]]"
- "[[DragonScale Memory]]"
- "[[claude-obsidian-v1.4-release-session]]"
---
# 2026-04-24 v1.6.0 Release Session
A same-day release cycle covering v1.5.0, v1.5.1, and v1.6.0.
This session took DragonScale from a three-mechanism opt-in extension to a four-mechanism opt-in extension, with a hardening point release in the middle.
**Public release notes**: [docs/releases/v1.6.0.md](../../docs/releases/v1.6.0.md). That file is the user-facing artifact and the source to paste into a `gh release create v1.6.0` body. This session page is the internal engineering record.
Ground truth for this page comes from:
- `CHANGELOG.md` entries `[1.5.0]`, `[1.5.1]`, and `[1.6.0]`
- `wiki/log.md` entries for 2026-04-24 covering Phase 3.5, Phase 3.6, and Phase 4
- current repository state for file existence, tags, and commit history
## Release Sequence
- `v1.5.0`: Phase 3.5, morning. Cross-phase hardening, opt-in DragonScale installer, reproducible tests, `CHANGELOG.md`, `Makefile`, version sync.
- `v1.5.1`: Phase 3.6, afternoon. Five surgical hardening fixes across tiling security, rollout baseline, AGENTS docs, wiki-ingest wording, and install guide versioning.
- `v1.6.0`: Phase 4, late. DragonScale Mechanism 4 shipped as opt-in boundary-first autoresearch, with the new scorer script, new tests, and no-topic autoresearch candidate flow.
## Release Summary
The morning release, v1.5.0, was the hardening pass that closed the hold-ship audit items accumulated across Phases 1 through 3.
The afternoon release, v1.5.1, was a narrow correction pass that fixed five remaining inconsistencies and one tiling write-path confinement issue before Phase 4 moved forward.
The late release, v1.6.0, shipped the previously deferred fourth DragonScale mechanism and completed the opt-in DragonScale set described in `[[DragonScale Memory]]`.
No git tag was created for v1.5.0, v1.5.1, or v1.6.0.
No push to `origin/main` happened during this release cycle.
`git tag` verifies that only pre-DragonScale tags exist locally:
- `v1.1`
- `v1.4.0`
- `v1.4.1`
- `v1.4.2`
- `v1.4.3`
## Phase Timeline For 2026-04-24
### Morning: Phase 3.5 to v1.5.0
This was the cross-phase hardening release.
The goal was to close the 10 hold-ship items found by the holistic audit across the earlier DragonScale phases.
The release added the missing installer, test harness, and changelog artifacts that made the extension reproducible instead of partially documented.
Mechanism 4 remained intentionally unshipped at this point.
The spec still marked it as not implemented, and `/autoresearch` was unchanged.
The release also synchronized plugin and marketplace version strings to `1.5.0`.
### Afternoon: Phase 3.6 to v1.5.1
This was a targeted hardening point release.
The work did not expand scope.
It corrected five issues that mattered for correctness, consistency, or security:
- tiling report path confinement
- rollout baseline date
- AGENTS skill-table and compatibility wording
- wiki-ingest wording about immutable `.raw/` versus maintained manifest
- install guide version drift
The result was a smaller, cleaner release state before Mechanism 4 moved from proposal to shipped code.
### Late: Phase 4 to v1.6.0
This was the feature release that shipped boundary-first autoresearch as DragonScale Mechanism 4.
The new scorer computes frontier candidates from the wikilink graph and exposes them when `/autoresearch` is invoked without a topic in a DragonScale-enabled vault.
The mode remained opt-in and was labeled as agenda control throughout the implementation and documentation.
Versions were then synced to `1.6.0` in `plugin.json` and `marketplace.json`.
## What Shipped In v1.5.0
### Added
- `skills/wiki-fold/` as the shipped opt-in fold operator for Mechanism 1. The changelog describes it as extractive and structurally idempotent, with dry-run by default and explicit commit mode.
- `scripts/allocate-address.sh` and the `address: c-NNNNNN` convention for Mechanism 2. The allocator is flock-guarded and supports re-ingest idempotency through `.raw/.manifest.json address_map`.
- `scripts/tiling-check.py` for Mechanism 3. The checker uses local `nomic-embed-text` through ollama and exposes conservative seeded thresholds for duplicate-page review.
- `wiki/concepts/DragonScale Memory.md` as the full design spec for the extension at v0.3 during this release.
- `bin/setup-dragonscale.sh` as the idempotent DragonScale installer.
- a reproducible `tests/` suite for allocator and tiling checks, runnable through `make test`
- `Makefile` developer targets for testing, setup, and cleanup
- `CHANGELOG.md` as the first explicit release ledger for this branch of work
### Changed
- `hooks/hooks.json` stages `.vault-meta/` in addition to `wiki/` and `.raw/`, so DragonScale runtime state is captured by the auto-commit hook
- `skills/wiki-ingest/SKILL.md` and `skills/wiki-lint/SKILL.md` gained opt-in DragonScale sections behind feature detection, while preserving default behavior for vaults that have not adopted DragonScale
- `agents/wiki-ingest.md` added the single-writer rule for address assignment
- `agents/wiki-lint.md` documented Address Validation and Semantic Tiling checks
- stale `allowed-tools` frontmatter was removed from `wiki-ingest` and `wiki-lint` to match the kepano-style `name` plus `description` convention for those files
- version strings were synced across plugin metadata and documentation
### Security
`scripts/tiling-check.py` defaults `OLLAMA_URL` to localhost only.
Remote endpoints require the `--allow-remote-ollama` flag.
Symlinks and vault-root escapes are rejected before any read.
### Explicitly Not In v1.5.0
Mechanism 4 was still a future proposal in this release.
The changelog states that boundary-first autoresearch did not ship in v1.5.0 and that `skills/autoresearch/SKILL.md` was unchanged.
That matters because the same day later reversed this state in v1.6.0.
## What Shipped In v1.5.1
v1.5.1 was intentionally narrow.
It fixed five concrete issues and did not introduce a new mechanism.
### Fixed
- `scripts/tiling-check.py`: the `--report PATH` flag is now resolved against `VAULT_ROOT` and rejected if it escapes, preventing accidental or hostile writes outside the vault
- `.vault-meta/legacy-pages.txt`: rollout baseline corrected from `2026-04-24` to `2026-04-23`, which matches the earliest addressed page in the seed vault
- `AGENTS.md`: `wiki-fold` added to the skills table, and the blanket statement about all skills using only `name` and `description` was narrowed to newer skills only
- `skills/wiki-ingest/SKILL.md`: clarified the difference between immutable user-dropped source documents in `.raw/` and the maintained `.raw/.manifest.json`
- `docs/install-guide.md`: version updated from `1.2.0` to `1.5.0`, with a DragonScale optional-install callout
### Why v1.5.1 Existed
The log entry describes this as pre-Phase-4 hardening.
That is the right framing.
It reduced drift across docs, setup state, and security behavior before the Mechanism 4 rollout.
## What Shipped In v1.6.0
### Added
- boundary-first autoresearch as DragonScale Mechanism 4, still opt-in
- `scripts/boundary-score.py`, which computes `(out_degree - in_degree) * recency_weight` over the wikilink graph
- `/autoresearch` without a topic now offers the top five frontier pages as candidate research targets when DragonScale is present
- `tests/test_boundary_score.py` with 35 unit tests covering parsing, recency weight, wikilink extraction, graph construction, scoring, and CLI behavior
- `make test-boundary`, integrated into `make test`
### Changed
- `skills/autoresearch/SKILL.md` gained a Topic Selection section with explicit, boundary-first, and user-ask paths
- `commands/autoresearch.md` documents no-topic usage for the two relevant modes
- `wiki/concepts/DragonScale Memory.md` flipped Mechanism 4 from not implemented to shipped, added the exact scoring formula, and bumped the spec to v0.4
- version metadata was synced to `1.6.0` across plugin metadata
### Scope And Behavior
The log entry is more detailed than the changelog and records the operating constraints clearly:
- the mode is opt-in
- the mode is labeled as agenda control
- helper failure falls back to asking the user
- self-loops, unresolved targets, meta-targets, symlinks, and vault escapes are excluded
- code-fence parsing handles both backticks and tildes with length-aware closure rules
- stale pages approach zero recency weight instead of receiving a floor
### Why v1.6.0 Matters
This is the release that completed the originally proposed four-part DragonScale design in shipped form.
It also changed `/autoresearch` from topic-only operation to a dual-mode flow that can surface candidate frontiers while still keeping user choice explicit.
## DragonScale Mechanisms: Opt-In Status
All four mechanisms are opt-in.
No mechanism is always-on for base vault adopters.
1. Fold operator (Mechanism 1). Shipped as `skills/wiki-fold/`. Dry-run verified. No fold committed in this vault.
2. Deterministic page addresses (Mechanism 2). Shipped via `scripts/allocate-address.sh` and `address: c-NNNNNN`. Feature-detected by ingest and lint flows.
3. Semantic tiling lint (Mechanism 3). Shipped via `scripts/tiling-check.py`. Uses local ollama embedding flow and remains optional.
4. Boundary-first autoresearch (Mechanism 4). Shipped in v1.6.0 via `scripts/boundary-score.py` and no-topic `/autoresearch` candidate selection.
## Verified New Files Mentioned In This Session
The following files were explicitly requested for verification and do exist in the repository:
- `scripts/boundary-score.py`: yes. New Mechanism 4 scorer in v1.6.0.
- `tests/test_boundary_score.py`: yes. New Mechanism 4 unit tests in v1.6.0.
- `bin/setup-dragonscale.sh`: yes. New opt-in installer in v1.5.0.
- `CHANGELOG.md`: yes. Created in v1.5.0.
- `Makefile`: yes. Created in v1.5.0 and later extended in v1.6.0.
Additional new files recorded in the 2026-04-24 log for Phase 3.5 also include:
- `tests/test_allocate_address.sh`
- `tests/test_tiling_check.py`
## Testing And Validation Notes
The release log gives exact validation points that are worth preserving here.
For v1.5.0:
- `make test` ran 12 shell assertions for the allocator
- `make test` ran 18 Python assertions for tiling-check
- no ollama dependency was required for those core tests
For v1.6.0:
- `tests/test_boundary_score.py` added 35 unit tests
- `make test-boundary` was added and folded into `make test`
The session also records adversarial review rounds for each phase:
- Phase 3 reached final verdict `10/10 accept`
- Phase 3.5 recorded `5/5 accept` on the doc and agent fixes plus `10/10 accept` on the final holistic audit pass
- Phase 4 reached pass after three adversarial rounds
Those review outcomes explain why the day was split into a hardening release, a point release, and then the final feature release.
## Git State And Release State
### Version State
Local metadata was bumped to `1.5.0`, then `1.5.1`, then `1.6.0` across the release cycle.
The user explicitly noted that v1.6.0 shipped locally and that no release tag exists for it.
Current repo checks support that statement.
### Tag State
`git tag` returns:
- `v1.1`
- `v1.4.0`
- `v1.4.1`
- `v1.4.2`
- `v1.4.3`
There is no local tag for `v1.5.0`, `v1.5.1`, or `v1.6.0`.
### Push State
The 2026-04-24 log entries repeatedly state `No push` or `no push`.
This release session remained local.
There was no push to `origin/main`.
### DragonScale Commit Range
The earliest DragonScale-labeled commit in repository history is:
- `16d9923` `feat: add flock-guarded address allocator for DragonScale Mechanism 2`
The latest commit in the release-phase DragonScale range before later wiki auto-commits is:
- `09399ae` `chore: bump to v1.6.0 with Phase 4 + Phase 3.6 CHANGELOG entries`
For the feature endpoint specifically, the latest DragonScale mechanism commit is:
- `ad1a1d0` `feat: autoresearch integrates DragonScale Mechanism 4 (opt-in)`
This page treats `16d9923` through `09399ae` as the practical release-session range, because the latter is the final version-sync commit that closed the feature release.
## Key Lessons
These are pulled from the `wiki/hot.md` Key Lessons section current at the time of this session.
1. Cross-phase audits are essential. Individual phase reviews miss drift between phases.
2. Opt-in feature detection (`[ -x script ] && [ -f state ]`) preserves default plugin behavior for adopters and non-adopters alike.
3. PostToolUse hook matcher is `Write|Edit`. Bash writes do not fire it. Scripts that mutate tracked state must be Bash-only to avoid side-effect commits.
4. Seed-vault self-consistency matters. If the spec says post-rollout pages need addresses, the concept page itself has to have one.
5. Codex adversarial review rounds stop when the punch list is empty, not when the author feels done.
## Session Shape Compared With v1.4
The earlier `[[claude-obsidian-v1.4-release-session]]` documented a broad ecosystem-response cycle that bundled research, audit response, style cleanup, security history rewrite, and a plugin install hotfix.
This 2026-04-24 session was narrower and more implementation-focused.
The main pattern was:
- complete the missing hardening work for existing DragonScale mechanisms
- correct the remaining drift with a point release
- then ship the previously deferred fourth mechanism
That sequencing was justified by the log and changelog.
Mechanism 4 was not simply appended to an unstable tree.
It was delayed until the earlier mechanism set had been hardened and the docs aligned.
## What This Session Did Not Do
It did not create release tags for the three versions shipped that day.
It did not push any of the DragonScale release work to `origin/main`.
It did not make DragonScale mandatory for users who only want the base wiki plugin.
It did not change the fact that all DragonScale mechanisms remain feature-detected and opt-in.
## Canonical Release Narrative
If this day needs to be summarized in one paragraph later, the clean version is this:
Morning v1.5.0 made DragonScale reproducible and internally consistent. Afternoon v1.5.1 cleaned up the remaining hardening issues. Late v1.6.0 shipped the previously deferred boundary-first autoresearch mechanism, completing the four-part DragonScale extension without changing the plugin's opt-in default posture.
## Verified Facts Worth Reusing
- `CHANGELOG.md` contains explicit entries for `[1.5.0]`, `[1.5.1]`, and `[1.6.0]`
- `wiki/log.md` contains same-day entries for Phase 3.5, Phase 3.6, and Phase 4
- `plugin.json` and `marketplace.json` are at `1.6.0`
- the DragonScale installer exists as `bin/setup-dragonscale.sh`
- the Mechanism 4 scorer exists as `scripts/boundary-score.py`
- the Mechanism 4 tests exist as `tests/test_boundary_score.py`
- `Makefile` and `CHANGELOG.md` exist
- only pre-DragonScale tags are present locally
- there was no push to `origin/main`
## Closing Note
The important distinction for future sessions is that `v1.5.0`, `v1.5.1`, and `v1.6.0` are real local release states with changelog and log backing, but they are not git-tagged releases in this repository snapshot.
wiki/meta/boundary-frontier-2026-04-24.md
-67
View File
@@ -1,67 +0,0 @@
---
type: meta
title: "Boundary Frontier Snapshot (2026-04-24)"
updated: 2026-04-24
tags:
- meta
- dragonscale
- mechanism-4
status: snapshot
related:
- "[[DragonScale Memory]]"
- "[[log]]"
- "[[hot]]"
---
# Boundary Frontier Snapshot (2026-04-24)
Navigation: [[index]] | [[log]] | [[DragonScale Memory]]
First end-to-end run of DragonScale Mechanism 4 (`scripts/boundary-score.py`) against this vault. Generated from `./scripts/boundary-score.py --json --top 7` at 2026-04-24T08:49:16Z.
## What this is
This is a scoring snapshot, not a prescription. The boundary score heuristic surfaces pages that are outward-pointing and recently-touched as candidates for `/autoresearch` to extend. It is explicitly agenda-control per the [[DragonScale Memory]] spec, v0.4, Mechanism 4: the ranking shapes what the agent researches next, and a user should accept, override, or decline any candidate.
Formula: `boundary_score(p) = (out_degree(p) - in_degree(p)) * exp(-age_days / 30)`.
No recency floor. Pages older than ~90 days approach zero weight by design, so a stale hub does not dominate the frontier.
## Frontier (top 7, score > 0)
| # | score | out | in | age_d | title | path |
|---|---|---|---|---|---|---|
| 1 | 4.693 | 8 | 0 | 16 | Claude + Obsidian Ecosystem Research | wiki/sources/claude-obsidian-ecosystem-research.md |
| 2 | 4.000 | 4 | 0 | 0 | DragonScale Memory | wiki/concepts/DragonScale Memory.md |
| 3 | 1.702 | 3 | 0 | 17 | How does the LLM Wiki pattern work? | wiki/questions/How does the LLM Wiki pattern work.md |
| 4 | 1.135 | 2 | 0 | 17 | Wiki vs RAG | wiki/comparisons/Wiki vs RAG.md |
| 5 | 0.717 | 1 | 0 | 10 | SEO Drift Monitoring | wiki/concepts/SEO Drift Monitoring.md |
| 6 | 0.717 | 1 | 0 | 10 | Search Experience Optimization (SXO) | wiki/concepts/Search Experience Optimization.md |
| 7 | 0.717 | 1 | 0 | 10 | Semantic Topic Clustering | wiki/concepts/Semantic Topic Clustering.md |
22 scoreable pages total (meta, fold, and index pages excluded).
## Reading the result
- Row 1 is the ecosystem research source. It links out to eight entity pages and is not linked back, which is expected for a raw source: it seeds the graph rather than being referenced by it. The score is correct; following this candidate would extend one of its eight entities rather than re-examining the source itself.
- Row 2 (DragonScale Memory) has age_days=0 and zero in-degree. This is a fresh concept page not yet linked back by any discussion. A legitimate frontier signal.
- Rows 3-7 are older pages (~10 to 17 days) with modest out-degree. The recency decay correctly damps them relative to fresh pages.
- No page ranks on pure recency with zero out-degree, because the formula multiplies degree-delta by recency.
## Calibration note
The halflife of 30 days was chosen as a default, not a tuned value. If this vault grows past ~100 pages and out-degree patterns change, the halflife should be reviewed alongside the weighting between degree and recency. The [[DragonScale Memory]] spec explicitly tags these as seed values, not literature-backed.
## Reproduce
```
./scripts/boundary-score.py --json --top 7
```
Read-only. Requires python3 only. No DragonScale setup needed to run the scorer itself.
## Connections
- [[DragonScale Memory]]: spec, Mechanism 4
- [[log]]: operation log
- [[hot]]: recent context
wiki/meta/claude-obsidian-cover-16x9.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 403 KiB

wiki/meta/claude-obsidian-cover-square.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 363 KiB

wiki/meta/claude-obsidian-gif-1x1.gif
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 847 KiB

wiki/meta/claude-obsidian-gif-cover-16x9.gif
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.3 MiB

wiki/meta/claude-obsidian-v1.2.0-release-session.md
-116
View File
@@ -1,116 +0,0 @@
---
type: session
title: "claude-obsidian v1.2.0 Release Session"
created: 2026-04-07
updated: 2026-04-07
tags:
- session
- release
- plugin
- github
status: evergreen
related:
- "[[getting-started]]"
- "[[index]]"
- "[[overview]]"
- "[[LLM Wiki Pattern]]"
---
# claude-obsidian v1.2.0 Release Session
Full build, audit, polish, and community release of the claude-obsidian plugin + vault kit. Previously named `cosmic-brain`.
---
## What Was Built
### Phase 1 — Critical Fixes
- `marketplace.json`: version corrected `1.0.0→1.2.0`, owner metadata updated
- `main.canvas`: removed 5 broken file node references (gitignored files that don't exist for community users)
- `community-plugins.json`: deduplicated from 6→4 canonical entries: `[excalidraw, banners, calendar, thino]`
### Phase 2 — Vault Onboarding
- `wiki/getting-started.md`: new onboarding page inside the vault (3-step quick start, hot cache explanation, command reference, navigation links)
- `wiki/index.md`: Entities, Questions, Comparisons sections populated with existing seed pages
- `wiki/meta/dashboard.md`: Dataview queries fixed — was querying `answer_quality` and `confidence` fields that don't exist in seed pages; replaced with `status` and `updated`
- `CLAUDE.md`: placeholder text replaced with actual vault description
- `wiki/canvases/welcome.canvas`: CTA node added pointing to getting-started and `/wiki`
### Phase 3 — README + Docs
- README: complete pre-installed plugins table, CSS snippets section, Banner usage section, file structure updated
- `bin/setup-vault.sh`: success message now lists all 4 pre-installed plugins and 3 CSS snippets
### Phase 4 — PDF Install Guide
- `docs/install-guide.md`: full printable install guide (prerequisites, 3 install options, first steps, command reference, plugin guide, MCP setup, troubleshooting)
- `docs/install-guide.pdf`: 159KB, generated via `npx md-to-pdf`
### Phase 5 — Version Bump
- `plugin.json` and `marketplace.json` bumped to `1.2.0`
---
## Rename: cosmic-brain → claude-obsidian
Full project rename executed:
- GitHub repos renamed: `AgriciDaniel/cosmic-brain` → `AI-Marketing-Hub/claude-obsidian` (public), `avalonreset-pro/cosmic-brain` → `avalonreset-pro/claude-obsidian` (private)
- Local directory: `~/cosmic-brain/` → `~/claude-obsidian/`
- All text references updated across 14 files via sed
- `wiki/meta/cosmic-brain-cover.gif` renamed to `wiki/meta/claude-obsidian-cover.gif`
---
## Legal & Security
### Security Audit
- No API keys, tokens, or secrets found in any tracked file
- No private keys or certificates
- All credential references in docs are placeholder values
- Excalidraw `main.js` correctly NOT tracked despite audit agent claiming otherwise
### Legal Fixes
- `LICENSE`: MIT license file created (was declared in plugin.json but file was missing)
- `ITS-Dataview-Cards.css` + `ITS-Image-Adjustments.css`: GPL-2.0 attribution headers added
### .gitignore Tightened
Added rules to prevent future accidental commits of: video files (`*.mkv`, `*.mp4`), transcripts, scratch canvases (`Untitled *.canvas`, `*Images.canvas`), and personal images in vault root.
---
## Visual / README
### GIFs and Images
- New Claude Obsidian branded assets added (16x9 cover GIF, 1x1 GIF, static PNGs)
- Compressed: `gif-cover-16x9.gif` 2.6MB→1.3MB (50%), `gif-1x1.gif` 2.6MB→848KB (68%) — via FFmpeg palette optimization, scaled to 960px/640px, 15fps, 128-color palette
- Example screenshots added: `image-example-graph-view.png`, `image-example-wiki-map-view.png`
### README Structure (top to bottom)
1. `claude-obsidian-gif-cover-16x9.gif` — header
2. Description text
3. `welcome-canvas.gif` — What It Does demo (full width)
4. Descriptive paragraphs
5. `image-example-graph-view.png` + `image-example-wiki-map-view.png` — side by side screenshots
6. Quick Start → Commands → Cross-Project → Six Modes → What Gets Created → MCP → Plugins → CSS Snippets → Banner → File Structure → AutoResearch → Seed Vault
7. `wiki-graph-grow.gif` + `workflow-loop.gif` — bottom of Seed Vault section
---
## Repository State
| Repo | Visibility | URL |
|------|-----------|-----|
| AI-Marketing-Hub/claude-obsidian | Public | https://github.com/AI-Marketing-Hub/claude-obsidian |
| avalonreset-pro/claude-obsidian | Private | https://github.com/avalonreset-pro/claude-obsidian |
Community install command: `claude plugin install github:AI-Marketing-Hub/claude-obsidian`
Future updates: `git push origin main && git push community main`
---
## Key Decisions
- **Rename to claude-obsidian**: clearer branding, immediately communicates the Claude + Obsidian pairing
- **avalonreset-pro repo is private**: community members only, not public
- **Excalidraw main.js excluded from git**: 8MB downloaded by `setup-vault.sh` at setup time
- **Bundled plugin redistribution**: acceptable — all 4 plugins are publicly distributed through Obsidian's community plugin system
- **GIF compression strategy**: palette reduction (256→128 colors) + resolution scaling gives 50-68% savings with no visible quality loss at GitHub's rendering width
wiki/meta/claude-obsidian-v1.4-release-session.md
-278
View File
@@ -1,278 +0,0 @@
---
type: session
title: "claude-obsidian v1.4 Release Session"
created: 2026-04-08
updated: 2026-04-08
tags:
- meta
- session
- release
- audit-response
status: evergreen
related:
- "[[claude-obsidian-ecosystem]]"
- "[[cherry-picks]]"
- "[[full-audit-and-system-setup-session]]"
- "[[claude-obsidian-v1.2.0-release-session]]"
- "[[LLM Wiki Pattern]]"
sources:
- "[[claude-obsidian-ecosystem-research]]"
---
# claude-obsidian v1.4 Release Session
A complete release cycle covering v1.1, v1.4.0, and v1.4.1. Includes ecosystem research, external audit response, multi-agent compatibility rollout, full em-dash style cleanup, git history scrub for privacy, and a hotfix for the plugin install command syntax.
## Release Sequence
| Version | What shipped |
|---|---|
| v1.1 | URL ingestion, image/vision ingestion, delta tracking manifest, 3 new skills (defuddle, obsidian-bases, obsidian-markdown), multi-depth wiki-query modes, PostToolUse auto-commit hook, removal of invalid `allowed-tools` frontmatter field |
| v1.4.0 | Dataview to Bases migration, Canvas JSON 1.0 spec completeness, hooks hardening plus PostCompact, MCP setup hardened with Obsidian CLI option, custom callouts documented, 6 multi-agent bootstrap files, 249 em dashes scrubbed, security-rewrote git history to remove a placeholder email |
| v1.4.1 | Hotfix for the wrong plugin install command syntax in README and docs/install-guide.md |
## v1.1: First Feature Release of This Session
Shipped in response to an internal quality check against the wider ecosystem (16+ Claude plus Obsidian projects researched, filed in [[claude-obsidian-ecosystem]]). The highest-value features from competing implementations were cherry-picked and shipped as v1.1.
### New skills (Agent Skills spec compliant)
- `skills/defuddle/SKILL.md`: strips ads, nav, and clutter from web pages before URL ingestion. Saves 40 to 60 percent on tokens for typical articles.
- `skills/obsidian-markdown/SKILL.md`: full reference for Obsidian Flavored Markdown (wikilinks, embeds, all callout types, properties, math, Mermaid). Cross-references kepano/obsidian-skills as the authoritative source.
- `skills/obsidian-bases/SKILL.md`: native Obsidian Bases `.base` file syntax. Uses correct `filters/views/formulas` structure (NOT Dataview-style `from/where`). Rewritten mid-session after the first attempt used the wrong syntax.
### wiki-ingest upgrades
- **URL ingestion**: passes any `https://` URL directly. Uses WebFetch, optionally pipes through defuddle, saves to `.raw/articles/`, then runs the normal ingest pipeline.
- **Image/vision ingestion**: `.png`, `.jpg`, `.gif`, `.webp`, etc. Claude reads the image natively, extracts text via OCR and concepts via vision, saves the description to `.raw/images/`, then ingests.
- **Delta tracking**: `.raw/.manifest.json` tracks MD5 hash per source, timestamps, and the pages produced. Re-running ingest on unchanged files skips them automatically. Override with "force ingest".
### wiki-query multi-depth modes
Three query tiers:
- **Quick** (`query quick: ...`): hot.md plus index.md only. About 1,500 tokens. Best for fact lookups.
- **Standard** (default): hot plus index plus 3 to 5 relevant pages. About 3,000 tokens. Best for most questions.
- **Deep** (`query deep: ...`): full wiki cross-reference plus optional web search supplement. About 8,000+ tokens. Best for synthesis, comparisons, "tell me everything about X".
### Hook: PostToolUse auto-commit
Every `Write` or `Edit` tool call to `wiki/` or `.raw/` triggers `git add` and `git commit` automatically. Guarded by `[ -d .git ]` so it never errors in non-git directories, and by `git diff --cached --quiet` so it never creates empty commits. Matcher: `Write|Edit`.
### Critical fix: `allowed-tools` frontmatter removed
The Agent Skills spec only supports `name`, `description`, `argument-hint`, `compatibility`, `disable-model-invocation`, `license`, `metadata`, and `user-invokable` fields in SKILL.md frontmatter. The `allowed-tools` field was never valid and was being silently ignored. Removed from all 10 SKILL.md files to match the kepano/obsidian-skills authoritative convention.
## v1.4.0: External Audit Response
External auditor delivered a 21-source review (the "compass artifact") against Agent Skills spec, Claude Code hooks, Obsidian v1.9 through v1.12, and JSON Canvas 1.0. Initial audit score: 6.5/10. Many findings were already resolved in v1.1 (the audit was conducted against a snapshot from before that release). The remaining valid findings became v1.4.0. Full findings and prioritization are in [[cherry-picks]].
### Tier 1: Critical fixes
**Dataview to Bases migration** (the biggest correctness fix). Obsidian Bases shipped as a core plugin in v1.9.10 (August 2025), providing native database-like views that replace Dataview for most use cases. Created `wiki/meta/dashboard.base` with six views (Recent Activity, Seed Pages, Entities Missing Sources, Open Questions, Comparisons, Sources). Updated `wiki/meta/dashboard.md` to embed the new base file as primary and keep the legacy Dataview queries as optional fallback. Reorganized README plugins section to recommend Bases (core, no install needed) as primary and mark Dataview as optional/legacy.
**Canvas JSON 1.0 spec completeness**. Added previously missing fields to `skills/canvas/references/canvas-spec.md`:
- Group nodes: `background` (string path) and `backgroundStyle` (`cover`, `ratio`, `repeat`)
- Edges: `fromEnd` (defaults to `"none"`) and `toEnd` (defaults to `"arrow"`). Asymmetric defaults that produce a single arrow without explicit specification.
- Documented the official hex ID convention alongside the descriptive ID alternative.
### Tier 2: Important improvements
**Hooks hardening plus PostCompact**. `hooks/hooks.json` updated:
- SessionStart now uses both `command` and `prompt` types. The command runs `[ -f wiki/hot.md ] && cat wiki/hot.md || true` as the canonical safety check that works in non-vault sessions without erroring. Matcher: `startup|resume`.
- **NEW PostCompact hook** re-injects `wiki/hot.md` after context compaction. Critical insight: hook-injected context does NOT survive compaction, only `CLAUDE.md` does. Without this hook the hot cache disappears mid-session after any compact event.
- PostToolUse auto-commit now guarded by `[ -d .git ]` in addition to the existing safeguards.
- New `hooks/README.md` documents all four hooks plus the known plugin-hooks STDOUT bug (`anthropics/claude-code#10875`) and workarounds.
**MCP setup hardened**. `skills/wiki/references/mcp-setup.md` now has a `> [!warning]` callout above the `NODE_TLS_REJECT_UNAUTHORIZED: "0"` line explaining that it disables TLS verification process-wide (acceptable for `127.0.0.1` only). Added **Option D: Obsidian CLI** (Obsidian v1.12+) as the recommended alternative that avoids the TLS workaround entirely by using the native CLI via the Bash tool.
**Custom callouts documented**. The vault defines four custom callout types in `.obsidian/snippets/vault-colors.css`:
| Callout | Color | Icon | Use for |
|---|---|---|---|
| `contradiction` | reddish-brown | `lucide-alert-triangle` | New source conflicts with existing claim |
| `gap` | beige | `lucide-help-circle` | Topic has no source yet |
| `key-insight` | bright blue | `lucide-lightbulb` | Important takeaway worth highlighting |
| `stale` | gray | `lucide-clock` | Claim may be outdated |
Full documentation added to `skills/wiki/references/css-snippets.md` including built-in fallback equivalents for users who do not want the custom CSS. `skills/wiki-ingest/SKILL.md` got an explicit note that `[!contradiction]` depends on the CSS snippet.
### Tier 3: Multi-agent compatibility (low complexity, high reach)
Skills are already in the cross-platform Agent Skills format. The only thing missing was adapter files so other AI coding agents could discover them. Added:
| File | For |
|---|---|
| `AGENTS.md` | Codex CLI, OpenCode |
| `GEMINI.md` | Gemini CLI, Antigravity |
| `.cursor/rules/claude-obsidian.mdc` | Cursor (always-on rules) |
| `.windsurf/rules/claude-obsidian.md` | Windsurf Cascade |
| `.github/copilot-instructions.md` | GitHub Copilot |
| `bin/setup-multi-agent.sh` | Idempotent symlink installer that wires up `skills/` into each agent's expected location |
This turns claude-obsidian into a multi-agent plugin at near-zero compatibility cost. Pattern borrowed from [[Ar9av-obsidian-wiki]] which was the reference implementation for multi-agent support.
## Style Cleanup: Em Dash Scrub
Per user preference saved to feedback memory: never use em dashes (U+2014) or `--` as punctuation. Use periods, commas, colons, or parentheses instead. Hyphens in compound words (auto-commit, multi-agent) are fine.
Wrote a context-aware Python scrubber at `/tmp/scrub_em_dashes.py` with rules:
- Heading lines (`^#`): em dash becomes `:`
- List items (`^-`, `^|`): em dash becomes `:` (for label-description patterns)
- Prose: em dash becomes `.` with next word capitalized
**Result**: 249 em dashes removed across 26 files. Scrubbed every SKILL.md, every doc, every hook file, every bootstrap file, and marketplace.json. Manual smoothing required for:
- `skills/obsidian-markdown/SKILL.md`: 4 code-block annotation tables where the scrubber produced broken fragments. Converted to proper markdown tables.
- `skills/wiki-query/SKILL.md`: 4 "If X. Respond." fragments rewritten as "If X, respond."
- `bin/setup-multi-agent.sh`: 1 leftover em dash at end-of-line that the scrubber missed (only matched space-em-space). Plus one awkward echo string fixed.
The user-facing feedback was clear: "make it proper and natural". The scrubbed prose reads cleaner with the fragmented sentences smoothed out.
## Security: Email Removal and Git History Rewrite
A placeholder email `[scrubbed-email]` (which the user confirmed does not exist as a real address) was in `marketplace.json` plus two docs. Removed from working tree first, then rewrote git history to scrub it from all commits.
**Tool**: `git filter-repo` (available at `~/.pyenv/versions/3.12.4/bin/git-filter-repo`).
**Two passes required**:
1. `git filter-repo --replace-text /tmp/email-replacements.txt --force` scrubs blob contents across all commits.
2. `git filter-repo --replace-message /tmp/email-msg-replacements.txt --force` scrubs commit messages. The first pass caught 3 occurrences in file contents but missed 1 occurrence in a commit subject line. The second pass caught that.
**Replacement string**: `[scrubbed-email]==>***REMOVED***`
**Post-rewrite actions**:
- Re-added the `origin` remote that filter-repo removes for safety
- Moved `v1.4.0` tag forward to include the security commit (since v1.4.0 had not been consumed yet by any user)
- Force-pushed main plus both tags (`v1.1` and `v1.4.0`)
- Updated the v1.4.0 GitHub release notes to include a "Security Note" section
**Verification**: grep across all refs, all blobs, all commit messages returned zero matches for the scrubbed email string. GitHub release bodies checked for same: both v1.1 and v1.4.0 release pages clean.
**Caveat for other clones**: history rewrite means every commit hash changed. Any other machine or private `community` remote that has the repo still contains the old history. Those need `git fetch && git reset --hard origin/main` or a force push to clean up.
## v1.4.1: Plugin Install Command Hotfix
The v1.4.0 README and install guide showed this install command:
```bash
claude plugin install github:AI-Marketing-Hub/claude-obsidian
```
This form does not exist in Claude Code. Users trying it see:
```
Failed to install plugin "github:AI-Marketing-Hub/claude-obsidian": Plugin "github:AI-Marketing-Hub/claude-obsidian" not found in any configured marketplace
```
### The correct install flow (per `code.claude.com/docs/en/plugin-marketplaces`)
Plugin installation is a **two-step** process:
```bash
# Step 1: add the marketplace catalog
claude plugin marketplace add AI-Marketing-Hub/claude-obsidian
# Step 2: install the plugin from the catalog by name
claude plugin install claude-obsidian@claude-obsidian-marketplace
```
Where `claude-obsidian` is the plugin name (from `plugin.json`) and `claude-obsidian-marketplace` is the marketplace name (from `marketplace.json`). The `@` delimiter separates them.
### Why the confusion existed
There is no `claude plugin install github:owner/repo` shortcut. The marketplace abstraction is mandatory: Claude Code always fetches via a registered marketplace. A single-repo plugin like claude-obsidian is both the marketplace host and the plugin host, and the user must register the marketplace first before installing any plugin from it.
### Related CLI commands (useful to know)
| Command | What it does |
|---|---|
| `claude plugin marketplace list` | Show all registered marketplaces |
| `claude plugin marketplace add owner/repo` | Register a new marketplace from a GitHub repo |
| `claude plugin marketplace update <name>` | Refresh the marketplace catalog and re-clone |
| `claude plugin marketplace remove <name>` | Unregister a marketplace (also uninstalls its plugins) |
| `claude plugin install <plugin>@<marketplace>` | Install a specific plugin |
| `claude plugin list` | Show all installed plugins and their status |
| `claude plugin validate .` | Validate a marketplace.json, plugin.json, and frontmatter |
### Files changed in v1.4.1
- `README.md`: Option 2 install section rewritten with two-step flow
- `docs/install-guide.md`: same correction
- `.claude-plugin/plugin.json`: 1.4.0 to 1.4.1
- `.claude-plugin/marketplace.json`: both `metadata.version` and `plugins[0].version` bumped to 1.4.1
### Confirmed working
After v1.4.1 was published, the user ran the corrected commands and saw:
```
claude-obsidian@claude-obsidian-marketplace
Version: 1.4.1
Scope: user
Status: ✔ enabled
```
v1.4.1 installed at user scope and enabled.
## Key Lessons (Worth Remembering)
1. **Plugin install is always two-step**. There is no github shorthand form. `marketplace add` then `install plugin@marketplace`.
2. **`allowed-tools` is not a valid skill frontmatter field**. The Agent Skills spec only accepts `name`, `description`, `argument-hint`, `compatibility`, `disable-model-invocation`, `license`, `metadata`, `user-invokable`. kepano/obsidian-skills uses only `name` and `description` which is the gold standard convention.
3. **Obsidian Bases uses `filters/views/formulas`, not Dataview-style `from/where`**. Easy to confuse. Always check `help.obsidian.md/bases/syntax` for the current syntax.
4. **Canvas JSON 1.0 has asymmetric edge defaults**. `fromEnd` defaults to `"none"`, `toEnd` defaults to `"arrow"`. Omitting both produces a single arrow pointing from source to target.
5. **Hook-injected context does not survive context compaction**. Only `CLAUDE.md` does. Any plugin that injects context via SessionStart hooks should also add a PostCompact hook to restore it mid-session.
6. **`git filter-repo` needs two passes for full scrub**. `--replace-text` handles blob contents, `--replace-message` handles commit messages. Running only one leaves traces.
7. **`git filter-repo` removes the `origin` remote for safety**. Must re-add it manually before force-pushing.
8. **Marketplace name and plugin name can differ**. Our marketplace is `claude-obsidian-marketplace`, our plugin is `claude-obsidian`. The `@` delimiter disambiguates them.
9. **Style preference: no em dashes anywhere**. Periods, commas, colons, or parentheses instead. Applies to all prose, commit messages, release notes, file content. Hyphens in compound words are fine.
## Files Created in This Session
Summary of everything new or newly created:
| Path | Type | Purpose |
|---|---|---|
| `skills/defuddle/SKILL.md` | skill | Web page cleaner |
| `skills/obsidian-bases/SKILL.md` | skill | Obsidian Bases syntax |
| `skills/obsidian-markdown/SKILL.md` | skill | Full Obsidian syntax reference |
| `wiki/meta/dashboard.base` | bases dashboard | 6-view Bases dashboard |
| `wiki/comparisons/claude-obsidian-ecosystem.md` | comparison | 16+ project feature matrix |
| `wiki/concepts/cherry-picks.md` | concept | Prioritized feature backlog |
| `wiki/sources/claude-obsidian-ecosystem-research.md` | source | Research summary |
| `wiki/entities/Ar9av-obsidian-wiki.md` | entity | Multi-agent reference implementation |
| `wiki/entities/Nexus-claudesidian-mcp.md` | entity | Native Obsidian plugin |
| `wiki/entities/ballred-obsidian-claude-pkm.md` | entity | Goal cascade PKM |
| `wiki/entities/rvk7895-llm-knowledge-bases.md` | entity | Multi-depth query reference |
| `wiki/entities/kepano-obsidian-skills.md` | entity | Authoritative skill reference |
| `wiki/entities/Claudian-YishenTu.md` | entity | Native Obsidian plugin |
| `.raw/claude-obsidian-ecosystem-research.md` | raw source | Ecosystem research dump |
| `hooks/README.md` | doc | Hook documentation |
| `AGENTS.md` | bootstrap | Codex CLI / OpenCode |
| `GEMINI.md` | bootstrap | Gemini CLI / Antigravity |
| `.cursor/rules/claude-obsidian.mdc` | bootstrap | Cursor rules |
| `.windsurf/rules/claude-obsidian.md` | bootstrap | Windsurf Cascade |
| `.github/copilot-instructions.md` | bootstrap | GitHub Copilot |
| `bin/setup-multi-agent.sh` | script | Multi-agent symlink installer |
## Current Plugin State
- **Plugin installed**: `claude-obsidian@claude-obsidian-marketplace` version `1.4.1`, user scope, enabled
- **Releases on GitHub**: `v1.1`, `v1.4.0`, `v1.4.1`
- **10 skills** in `skills/`: wiki, wiki-ingest, wiki-query, wiki-lint, save, autoresearch, canvas, defuddle, obsidian-bases, obsidian-markdown
- **4 lifecycle hooks** in `hooks/hooks.json`: SessionStart, PostCompact, PostToolUse, Stop
- **6 multi-agent bootstrap files** covering Codex, OpenCode, Gemini, Cursor, Windsurf, GitHub Copilot
- **2 agents** in `agents/`: wiki-ingest, wiki-lint
## Deferred to v1.5.0
From the audit cherry-picks list, these items were identified but intentionally not included in v1.4.0:
- `/adopt` command for importing existing vaults (medium complexity, adds new surface)
- Vault graph analysis enhancement to wiki-lint (hub pages, cross-domain bridges, dead-ends)
- Semantic search via qmd MCP server (optional external dependency)
- Marp slide output from wiki queries (niche)
- Thinking mode vs Writing mode UX experiment
wiki/meta/dashboard.base
+10 -33
View File
@@ -7,10 +7,14 @@ formulas:
properties:
type:
displayName: Type
authors:
displayName: Authors
status:
displayName: Status
updated:
displayName: Updated
domain:
displayName: Domain
formula.age_days:
displayName: Days Since Edit
views:
@@ -25,44 +29,16 @@ views:
- status
- updated
- formula.age_days
limit: 15
- type: list
name: Seed Pages (Need Development)
filters:
and:
- status == "seed"
order:
- file.name
- updated
- type: list
name: Entities Missing Sources
filters:
and:
- file.inFolder("wiki/entities")
- or:
- "!sources"
- sources.length == 0
order:
- file.name
- type: list
name: Open Questions
filters:
and:
- file.inFolder("wiki/questions")
- or:
- status == "developing"
- status == "seed"
order:
- file.name
- updated
limit: 20
- type: table
name: Comparisons
name: Finite Element Concepts
filters:
and:
- file.inFolder("wiki/comparisons")
- file.inFolder("wiki/concepts")
order:
- file.name
- verdict
- domain
- status
- updated
- type: table
name: Sources
@@ -72,6 +48,7 @@ views:
- type == "source"
order:
- file.name
- authors
- author
- date_published
- updated
wiki/meta/dashboard.md
+15 -38
View File
@@ -1,7 +1,7 @@
---
type: meta
title: "Dashboard"
updated: 2026-04-08
updated: 2026-05-28
tags:
- meta
- dashboard
@@ -11,58 +11,35 @@ related:
- "[[overview]]"
- "[[log]]"
- "[[concepts/_index]]"
- "[[Compounding Knowledge]]"
- "[[Finite Element Method]]"
- "[[A Continuum Mechanics Based Four-Node Shell]]"
- "[[Four-Node-Quadrilateral-Shell-Element-MITC4]]"
- "[[MITC Study Notes]]"
- "[[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method]]"
- "[[On-the-Finite-Element-Analysis-of-Shell-Structures]]"
- "[[Solid Element Notes]]"
---
# Wiki Dashboard
Navigation: [[index]] | [[overview]] | [[log]] | [[hot]]
The dashboard uses **Obsidian Bases**. A core Obsidian feature shipped in v1.9.10 (August 2025). No plugin install required.
> [!tip] Embedded Bases view
> The interactive dashboard lives in [[dashboard.base]]. Open that file directly, or use the embed below.
![[dashboard.base]]
The dashboard uses Obsidian Bases. Open `wiki/meta/dashboard.base` directly.
---
## Legacy Dataview Dashboard (Optional)
## Current Focus
If you are on Obsidian < 1.9.10 or prefer Dataview, the queries below still work. Just install the Dataview community plugin.
- Sources: [[Finite Element Procedures]], [[Solid Element Notes]], [[A Continuum Mechanics Based Four-Node Shell]], [[Four-Node-Quadrilateral-Shell-Element-MITC4|Four-Node Quadrilateral Shell Element MITC4]], [[MITC Study Notes]], [[Dynamic-Buckling-Analysis-of-Shell-Structures-using-Finite-Element-Method|Dynamic Buckling Analysis of Shell Structures using Finite Element Method]], [[On-the-Finite-Element-Analysis-of-Shell-Structures|On the Finite Element Analysis of Shell Structures]]
- Domain: [[Computational Mechanics]]
- Main concepts: [[Finite Element Method]], [[Isoparametric Linear Solid Elements]], [[Solid Element Stiffness Integration]], [[Continuum Mechanics Based Four-Node Shell Element]], [[MITC4 Shell Element]], [[Shell Structure Asymptotic Behavior]], [[Shell Locking Phenomenon]], [[Dynamic Buckling Analysis]]
### Recent Activity
## Useful Queries
```dataview
TABLE type, status, updated FROM "wiki" SORT updated DESC LIMIT 15
```
### Seed Pages (Need Development)
```dataview
LIST FROM "wiki" WHERE status = "seed" SORT updated ASC
```
### Entities Missing Sources
```dataview
LIST FROM "wiki/entities" WHERE !sources OR length(sources) = 0
```
### Open Questions
```dataview
LIST FROM "wiki/questions" WHERE status = "developing" OR status = "seed" SORT updated DESC
```
### Comparisons
```dataview
TABLE verdict FROM "wiki/comparisons" SORT updated DESC
```
### Sources
```dataview
TABLE author, date_published, updated FROM "wiki/sources" WHERE type = "source" SORT updated DESC LIMIT 10
LIST FROM "wiki/concepts" WHERE contains(tags, "finite-element-method") SORT file.name ASC
```
wiki/meta/dragonscale-6-test-flow.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 101 KiB

wiki/meta/dragonscale-6-test-flow.svg
-82
View File
@@ -1,82 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 900 300" width="900" height="300" font-family="Space Grotesk, system-ui, -apple-system, sans-serif">
<rect width="900" height="300" fill="#0A0A0A"/>
<text x="450" y="36" fill="#F5F5F0" font-size="17" font-weight="700" text-anchor="middle">v1.6.0 end-to-end validation: six tests, all green</text>
<text x="450" y="56" fill="#888888" font-size="11" text-anchor="middle">Teams orchestration, codex gpt-5.4 for sub-agents, chair for integration</text>
<!-- Horizontal flow, 6 nodes evenly spaced -->
<!-- Centers at x = 90, 225, 360, 495, 630, 765; y = 150 -->
<!-- Connecting lines -->
<g stroke="#2D2D2D" stroke-width="1.5" fill="none">
<line x1="132" y1="150" x2="183" y2="150"/>
<line x1="267" y1="150" x2="318" y2="150"/>
<line x1="402" y1="150" x2="453" y2="150"/>
<line x1="537" y1="150" x2="588" y2="150"/>
<line x1="672" y1="150" x2="723" y2="150"/>
</g>
<!-- T0 -->
<g>
<circle cx="90" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="90" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T0</text>
<text x="90" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">ollama</text>
<text x="90" y="172" fill="#888888" font-size="9" text-anchor="middle">pull model</text>
<text x="90" y="218" fill="#888888" font-size="10" text-anchor="middle">nomic-embed-text</text>
<text x="90" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">274 MB, 15 s</text>
</g>
<!-- T1 -->
<g>
<circle cx="225" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="225" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T1</text>
<text x="225" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">M1</text>
<text x="225" y="172" fill="#888888" font-size="9" text-anchor="middle">dry-run k=3</text>
<text x="225" y="218" fill="#888888" font-size="10" text-anchor="middle">DRY-RUN OK</text>
<text x="225" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">8 children, no em-dashes</text>
</g>
<!-- T2 -->
<g>
<circle cx="360" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="360" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T2</text>
<text x="360" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">M2</text>
<text x="360" y="172" fill="#888888" font-size="9" text-anchor="middle">allocate</text>
<text x="360" y="218" fill="#888888" font-size="10" text-anchor="middle">counter 2 to 3</text>
<text x="360" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">c-000002 reserved</text>
</g>
<!-- T3 -->
<g>
<circle cx="495" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="495" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T3</text>
<text x="495" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">M3</text>
<text x="495" y="172" fill="#888888" font-size="9" text-anchor="middle">full tiling</text>
<text x="495" y="218" fill="#888888" font-size="10" text-anchor="middle">41 scanned, 21 embedded</text>
<text x="495" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">0 errors, 15 review pairs</text>
</g>
<!-- T4 -->
<g>
<circle cx="630" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="630" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T4</text>
<text x="630" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">M1</text>
<text x="630" y="172" fill="#888888" font-size="9" text-anchor="middle">commit</text>
<text x="630" y="218" fill="#888888" font-size="10" text-anchor="middle">fold committed</text>
<text x="630" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">115 lines, 8 children</text>
</g>
<!-- T6 -->
<g>
<circle cx="765" cy="150" r="42" fill="#111111" stroke="#16a34a" stroke-width="2"/>
<text x="765" y="140" fill="#16a34a" font-size="10" font-weight="700" text-anchor="middle">T6</text>
<text x="765" y="158" fill="#F5F5F0" font-size="14" font-weight="700" text-anchor="middle">M4</text>
<text x="765" y="172" fill="#888888" font-size="9" text-anchor="middle">autoresearch</text>
<text x="765" y="218" fill="#888888" font-size="10" text-anchor="middle">3 pages filed</text>
<text x="765" y="232" fill="#6a6a6a" font-size="9" text-anchor="middle">6 URLs fetched, sourced</text>
</g>
<!-- Verdict strip -->
<g>
<rect x="300" y="262" width="300" height="24" rx="12" fill="#16a34a" fill-opacity="0.15" stroke="#16a34a" stroke-width="1"/>
<text x="450" y="279" fill="#4ADE80" font-size="11" font-weight="700" text-anchor="middle">ACCEPT · make test green (74+ assertions)</text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 4.9 KiB

wiki/meta/dragonscale-frontier-graph.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 171 KiB

wiki/meta/dragonscale-frontier-graph.svg
-88
View File
@@ -1,88 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 900 500" width="900" height="500" font-family="Space Grotesk, system-ui, -apple-system, sans-serif">
<rect width="900" height="500" fill="#0A0A0A"/>
<text x="450" y="36" fill="#F5F5F0" font-size="17" font-weight="700" text-anchor="middle">Boundary-first autoresearch in action</text>
<text x="450" y="56" fill="#888888" font-size="11" text-anchor="middle">top-5 frontier from the 2026-04-24 run. Candidate picked, three pages filed.</text>
<!-- Left column: candidate list -->
<g>
<text x="60" y="100" fill="#E07850" font-size="11" font-weight="700" letter-spacing="2">TOP-5 FRONTIER</text>
<!-- #1 skipped -->
<rect x="50" y="116" width="310" height="44" rx="10" fill="#111111" stroke="#2D2D2D" stroke-width="1"/>
<text x="70" y="138" fill="#6a6a6a" font-size="10" text-anchor="start">1. Ecosystem Research</text>
<text x="340" y="138" fill="#6a6a6a" font-size="10" text-anchor="end">4.693</text>
<text x="70" y="152" fill="#dc2626" font-size="9">skipped: source page</text>
<!-- #2 skipped -->
<rect x="50" y="168" width="310" height="44" rx="10" fill="#111111" stroke="#2D2D2D" stroke-width="1"/>
<text x="70" y="190" fill="#6a6a6a" font-size="10">2. DragonScale Memory</text>
<text x="340" y="190" fill="#6a6a6a" font-size="10" text-anchor="end">4.000</text>
<text x="70" y="204" fill="#dc2626" font-size="9">skipped: self-reference</text>
<!-- #3 CHOSEN -->
<rect x="50" y="220" width="310" height="58" rx="10" fill="#1A1A1A" stroke="#4ADE80" stroke-width="2"/>
<text x="70" y="242" fill="#F5F5F0" font-size="12" font-weight="700">3. How does the LLM Wiki pattern work?</text>
<text x="340" y="242" fill="#F5F5F0" font-size="11" font-weight="700" text-anchor="end">1.702</text>
<text x="70" y="258" fill="#4ADE80" font-size="9" font-weight="700" letter-spacing="1">CHOSEN CANDIDATE</text>
<text x="70" y="271" fill="#888888" font-size="9">question page with gap, 6 URLs fetched for extension</text>
<!-- #4 -->
<rect x="50" y="286" width="310" height="44" rx="10" fill="#111111" stroke="#2D2D2D" stroke-width="1"/>
<text x="70" y="308" fill="#888888" font-size="10">4. Wiki vs RAG</text>
<text x="340" y="308" fill="#888888" font-size="10" text-anchor="end">1.135</text>
<text x="70" y="322" fill="#6a6a6a" font-size="9">eligible, not picked this round</text>
<!-- #5 -->
<rect x="50" y="338" width="310" height="44" rx="10" fill="#111111" stroke="#2D2D2D" stroke-width="1"/>
<text x="70" y="360" fill="#888888" font-size="10">5. SEO Drift Monitoring</text>
<text x="340" y="360" fill="#888888" font-size="10" text-anchor="end">0.717</text>
<text x="70" y="374" fill="#6a6a6a" font-size="9">eligible, not picked this round</text>
<!-- Formula footer -->
<text x="50" y="420" fill="#6a6a6a" font-size="10" font-weight="700">formula</text>
<text x="50" y="436" fill="#888888" font-size="10">score = (out_degree - in_degree) * exp(-age_days / 30)</text>
<text x="50" y="452" fill="#6a6a6a" font-size="9">halflife 30 days, no floor. 22 scoreable pages. meta excluded.</text>
</g>
<!-- Arrow from chosen candidate into synthesis -->
<g stroke="#4ADE80" stroke-width="2" fill="none">
<path d="M 365 249 Q 440 249 520 200" marker-end="url(#arrow-green)"/>
<path d="M 365 249 Q 440 249 520 249"/>
<path d="M 365 249 Q 440 249 520 298" marker-end="url(#arrow-green)"/>
<line x1="519" y1="249" x2="518" y2="250"/>
</g>
<defs>
<marker id="arrow-green" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto">
<path d="M 0 0 L 10 5 L 0 10 z" fill="#4ADE80"/>
</marker>
</defs>
<!-- Right column: 3 new pages filed -->
<g>
<text x="540" y="100" fill="#4ADE80" font-size="11" font-weight="700" letter-spacing="2">PAGES FILED</text>
<!-- New page 1 -->
<rect x="520" y="176" width="340" height="54" rx="10" fill="#111111" stroke="#4ADE80" stroke-width="1.5"/>
<text x="540" y="198" fill="#F5F5F0" font-size="12" font-weight="700">Persistent Wiki Artifact</text>
<text x="540" y="214" fill="#888888" font-size="9">44 lines · Karpathy gist + Obsidian docs</text>
<text x="540" y="226" fill="#6a6a6a" font-size="9">durable Markdown layer as the agent's memory object</text>
<!-- New page 2 -->
<rect x="520" y="238" width="340" height="54" rx="10" fill="#111111" stroke="#4ADE80" stroke-width="1.5"/>
<text x="540" y="260" fill="#F5F5F0" font-size="12" font-weight="700">Source-First Synthesis</text>
<text x="540" y="276" fill="#888888" font-size="9">42 lines · Karpathy gist + RAG arXiv 2005.11401</text>
<text x="540" y="288" fill="#6a6a6a" font-size="9">raw sources immutable, synthesis cites them</text>
<!-- New page 3 -->
<rect x="520" y="300" width="340" height="54" rx="10" fill="#111111" stroke="#4ADE80" stroke-width="1.5"/>
<text x="540" y="322" fill="#F5F5F0" font-size="12" font-weight="700">Query-Time Retrieval</text>
<text x="540" y="338" fill="#888888" font-size="9">44 lines · Karpathy gist + MemGPT arXiv 2310.08560</text>
<text x="540" y="350" fill="#6a6a6a" font-size="9">wiki query synthesis vs Obsidian in-vault search</text>
<!-- Agenda-control caveat -->
<rect x="520" y="400" width="340" height="60" rx="10" fill="#1A1A1A" stroke="#E07850" stroke-width="1"/>
<text x="540" y="420" fill="#E07850" font-size="10" font-weight="700" letter-spacing="2">AGENDA CONTROL</text>
<text x="540" y="436" fill="#888888" font-size="9">M4 does not just describe the vault; it shapes what</text>
<text x="540" y="450" fill="#888888" font-size="9">the agent researches next. User picks, overrides, declines.</text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 5.7 KiB

wiki/meta/dragonscale-mechanism-overview.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 136 KiB

wiki/meta/dragonscale-mechanism-overview.svg
-56
View File
@@ -1,56 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 500" width="800" height="500" font-family="Space Grotesk, system-ui, -apple-system, sans-serif">
<rect width="800" height="500" fill="#0A0A0A"/>
<text x="400" y="36" fill="#F5F5F0" font-size="17" font-weight="700" text-anchor="middle">DragonScale Memory: four mechanisms</text>
<text x="400" y="56" fill="#888888" font-size="11" font-weight="400" text-anchor="middle">opt-in, feature-gated, v1.6.0</text>
<!-- Card 1: Fold operator (stand-alone, no shared gate) -->
<g>
<rect x="40" y="90" width="355" height="140" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
<rect x="40" y="90" width="355" height="4" rx="2" fill="#E07850"/>
<text x="60" y="120" fill="#E07850" font-size="13" font-weight="700" letter-spacing="2">M1</text>
<text x="60" y="146" fill="#F5F5F0" font-size="15" font-weight="700">Fold operator</text>
<text x="60" y="168" fill="#888888" font-size="10">Flat extractive rollup of the last 2^k log entries</text>
<text x="60" y="184" fill="#888888" font-size="10">into a fold page. Dry-run default, commit explicit.</text>
<text x="60" y="212" fill="#6a6a6a" font-size="9">skills/wiki-fold · dry-run stdout-only, no residue</text>
</g>
<!-- Card 2: Addresses -->
<g>
<rect x="405" y="90" width="355" height="140" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
<rect x="405" y="90" width="355" height="4" rx="2" fill="#60A5FA"/>
<text x="425" y="120" fill="#60A5FA" font-size="13" font-weight="700" letter-spacing="2">M2</text>
<text x="425" y="146" fill="#F5F5F0" font-size="15" font-weight="700">Deterministic page addresses</text>
<text x="425" y="168" fill="#888888" font-size="10">Creation-order counter c-NNNNNN, flock-guarded,</text>
<text x="425" y="184" fill="#888888" font-size="10">recovers from max observed. Gap-tolerant.</text>
<text x="425" y="212" fill="#6a6a6a" font-size="9">scripts/allocate-address.sh · counter at 3 in this vault</text>
</g>
<!-- Card 3: Tiling -->
<g>
<rect x="40" y="250" width="355" height="140" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
<rect x="40" y="250" width="355" height="4" rx="2" fill="#8b5cf6"/>
<text x="60" y="280" fill="#8b5cf6" font-size="13" font-weight="700" letter-spacing="2">M3</text>
<text x="60" y="306" fill="#F5F5F0" font-size="15" font-weight="700">Semantic tiling lint</text>
<text x="60" y="328" fill="#888888" font-size="10">Embedding-based duplicate detection via local</text>
<text x="60" y="344" fill="#888888" font-size="10">ollama + nomic-embed-text. Banded thresholds.</text>
<text x="60" y="372" fill="#6a6a6a" font-size="9">scripts/tiling-check.py · first run: 0 errors, 15 review pairs</text>
</g>
<!-- Card 4: Boundary -->
<g>
<rect x="405" y="250" width="355" height="140" rx="16" fill="#111111" stroke="#2D2D2D" stroke-width="1.5"/>
<rect x="405" y="250" width="355" height="4" rx="2" fill="#4ADE80"/>
<text x="425" y="280" fill="#4ADE80" font-size="13" font-weight="700" letter-spacing="2">M4</text>
<text x="425" y="306" fill="#F5F5F0" font-size="15" font-weight="700">Boundary-first autoresearch</text>
<text x="425" y="328" fill="#888888" font-size="10">score = (out_degree - in_degree) * exp(-days/30).</text>
<text x="425" y="344" fill="#888888" font-size="10">Agenda control, not pure memory. User picks.</text>
<text x="425" y="372" fill="#6a6a6a" font-size="9">scripts/boundary-score.py · stdout-only, read-only</text>
</g>
<!-- Shared gate strip for M2/M3/M4 -->
<g>
<rect x="40" y="420" width="720" height="44" rx="10" fill="#1A1A1A" stroke="#2D2D2D" stroke-width="1"/>
<text x="60" y="440" fill="#E07850" font-size="11" font-weight="700" letter-spacing="2">SHARED GATE</text>
<text x="60" y="458" fill="#888888" font-size="10">.vault-meta/ presence enables M2, M3, M4 feature detection. M1 has no shared state. Remove .vault-meta/ to disable all three at once.</text>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 4.0 KiB

wiki/meta/full-audit-and-system-setup-session.md
-91
View File
@@ -1,91 +0,0 @@
---
type: session
title: "Full Audit, System Setup & Plugin Installation"
created: 2026-04-07
updated: 2026-04-07
tags:
- session
- audit
- setup
- plugin-install
status: evergreen
related:
- "[[claude-obsidian-v1.2.0-release-session]]"
- "[[getting-started]]"
- "[[index]]"
---
# Full Audit, System Setup & Plugin Installation
Post-release audit session. Covers comprehensive repo audit across 12 areas, 3 issue fixes, plugin installation into the local Claude Code system, folder rename, and memory save.
---
## Audit Results (12 Areas)
All 12 areas audited — 3 issues found, all fixed same session.
### Issues Found and Fixed
| Issue | Fix |
|-------|-----|
| `Cosmic Brain Clean.gif` tracked in git (personal asset) | Removed with `git rm --cached`, added `Cosmic Brain*.gif` to .gitignore |
| `Cosmic Brain Cover.png` tracked in git (personal asset) | Removed with `git rm --cached`, added `Cosmic Brain*.png` to .gitignore |
| `Welcome.md` tracked in git (Obsidian personal file) | Removed with `git rm --cached`, added `Welcome.md` to .gitignore |
| `vault-colors.css` comment said "cosmic-brain vault colors" | Updated to "claude-obsidian vault colors" |
| `docs/superpowers/plans/` not committed | Committed audit plan file |
### Clean Areas (no issues)
- Plugin manifests: all fields correct, version 1.2.0 consistent
- All 7 SKILL.md files: valid frontmatter, correct tools, complete instructions
- All 4 commands: mapped to correct skills, descriptions accurate
- Both agents: model/maxTurns/tools correct
- hooks/hooks.json: valid JSON, SessionStart + Stop hooks correct
- All .obsidian/*.json: community-plugins.json (4 entries), appearance.json (3 snippets), app.json, graph.json all valid
- All 4 Obsidian plugin manifests: complete, no personal data in data.json files
- All 3 CSS snippets: GPL-2.0 headers present, no stale references
- All 16 wikilinks resolve to valid files
- All 3 canvases valid JSON, no broken file node references
- README: all 6 images verified on disk, install commands correct, structure accurate
- Zero secrets in any tracked file, all API key references are placeholders
- Install simulation: all 7 skills, 4 commands, 2 agents discoverable, hooks valid
---
## Plugin Installation
claude-obsidian is now installed in the local Claude Code system:
```bash
# Registered as marketplace
claude plugin marketplace add AI-Marketing-Hub/claude-obsidian
# → claude-obsidian-marketplace registered (user scope)
# Installed plugin
claude plugin install claude-obsidian
# → claude-obsidian@claude-obsidian-marketplace (scope: user) ✓
```
To verify: `claude plugin list | grep claude-obsidian`
---
## System State
- Plugin repo: `~/claude-obsidian/` (git repo, both remotes live)
- Plugin installed: `claude-obsidian@claude-obsidian-marketplace` (user scope, enabled)
- Working folder renamed: `~/Desktop/Obsidian & Claude/` → `~/Desktop/claude-obsidian/`
- Karpathy Gist comment drafted (ready to post at gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
---
## Commands Available After Install
| Trigger | What happens |
|---------|-------------|
| `/wiki` | Setup check, scaffold, or continue |
| `ingest [file]` | Create 8–15 wiki pages from source |
| `/save` | File this conversation to wiki |
| `/autoresearch [topic]` | Autonomous web research loop |
| `/canvas` | Visual canvas operations |
| `lint the wiki` | Health check |
wiki/meta/image-example-graph-view.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 351 KiB

wiki/meta/image-example-wiki-map-view.png
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 212 KiB

wiki/meta/retrieval-benchmark-v1.7.md
-402
View File
@@ -1,402 +0,0 @@
---
type: meta
title: "v1.7 Retrieval Benchmark Corpus"
status: evergreen
updated: 2026-05-17
---
# v1.7 Retrieval Benchmark — 50 Queries
Used by the v1.7.0 audit (`docs/audits/v1.7.0-audit-2026-05-17.md`) to score
top-1 / top-5 accuracy of the hybrid retrieval pipeline (`scripts/retrieve.py`)
vs. the simulated v1.6 baseline (`scripts/baseline-v16.py`).
## Schema
Each query: `id`, `query`, `correct` (canonical page paths), `relevant`
(supporting paths), `category`, `rationale`. For negative queries, `correct`
is `null` and success is defined as "returns nothing OR returns only pages
in `relevant`."
Machine-parsable: every query block is bracketed by `### <id>` and ends
before the next `### ` or `## `. The scoring runner at
`scripts/benchmark-runner.py` reads this file directly.
## Scoring rules
- **top-1 success**: top result's `page_path` equals one of `correct[]`
- **top-5 success**: any of top-5 results' `page_path` is in `correct[]`
- For negative queries (correct=null): top-1 success if top result in `relevant[]` or no results; top-5 success if any top-5 in `relevant[]` or no results
Final scores reported as (top-1%, top-5%) per pipeline, broken down by category.
---
## Derived Queries (25)
### D1
- query: How does knowledge compound differently in a wiki versus traditional RAG?
- correct: wiki/concepts/Compounding Knowledge.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/comparisons/Wiki vs RAG.md
- category: derived
- rationale: Canonical treatment of why wiki accumulation produces more value over time vs. query-time re-derivation.
### D2
- query: What is the Hot Cache and why would a user enable it in their session?
- correct: wiki/concepts/Hot Cache.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/getting-started.md
- category: derived
- rationale: Direct explanation of the session context mechanism and its token-cost benefits.
### D3
- query: Tell me the three-layer architecture behind the LLM Wiki pattern.
- correct: wiki/concepts/LLM Wiki Pattern.md
- relevant: wiki/overview.md, wiki/index.md
- category: derived
- rationale: Explicit description of .raw, wiki, and CLAUDE.md layers.
### D4
- query: What does the wiki fold operator do and why use exponential batch sizes?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md, wiki/hot.md
- category: derived
- rationale: Mechanism 1 detailed explanation with 2^k justification and LSM analogy.
### D5
- query: How are deterministic page addresses assigned and what format do they use?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md
- category: derived
- rationale: Mechanism 2 spec with c-NNNNNN format and counter recovery rules.
### D6
- query: Explain semantic tiling lint and what cosine similarity threshold it uses.
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md, wiki/hot.md
- category: derived
- rationale: Mechanism 3 detailed treatment including banded thresholds and embeddings.
### D7
- query: What are the cherry-picked features claude-obsidian should implement next?
- correct: wiki/concepts/cherry-picks.md
- relevant: wiki/index.md, wiki/comparisons/claude-obsidian-ecosystem.md
- category: derived
- rationale: Explicit prioritized backlog from ecosystem research across tiers.
### D8
- query: What is the relationship between SVG diagrams and brand tokens in claude-obsidian assets?
- correct: wiki/concepts/SVG Diagram Style Guide.md
- relevant: wiki/log.md
- category: derived
- rationale: Canonical style reference with color palette, typography, and layout tokens.
### D9
- query: How does a user ingest a source document into claude-obsidian and what happens next?
- correct: wiki/getting-started.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/overview.md
- category: derived
- rationale: Three-step quick start walkthrough with expected output pages.
### D10
- query: What does the Pro Hub Challenge reward and what was the first winner?
- correct: wiki/concepts/Pro Hub Challenge.md
- relevant: wiki/entities/Claude SEO.md, wiki/log.md
- category: derived
- rationale: Community challenge structure and integration pattern with historical results.
### D11
- query: What is Search Experience Optimization and how does it read SERPs backwards?
- correct: wiki/concepts/Search Experience Optimization.md
- relevant: wiki/entities/Claude SEO.md, wiki/concepts/Semantic Topic Clustering.md
- category: derived
- rationale: Direct explanation of SXO methodology and its page-type mismatch detection.
### D12
- query: How does semantic topic clustering use overlapping URLs to detect content relationships?
- correct: wiki/concepts/Semantic Topic Clustering.md
- relevant: wiki/entities/Claude SEO.md, wiki/log.md
- category: derived
- rationale: Overlap scoring rules and hub-spoke architecture.
### D13
- query: What tracking rules does SEO Drift Monitoring enforce and where is the baseline stored?
- correct: wiki/concepts/SEO Drift Monitoring.md
- relevant: wiki/entities/Claude SEO.md
- category: derived
- rationale: 17 comparison rules across severity levels and SQLite persistence location.
### D14
- query: Who is Andrej Karpathy and why does he matter to this wiki project?
- correct: wiki/entities/Andrej Karpathy.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/index.md
- category: derived
- rationale: Founder attribution and origination of the pattern with notable quote.
### D15
- query: What version of Claude SEO shipped in April 2026 and how many skills does it have?
- correct: wiki/entities/Claude SEO.md
- relevant: wiki/log.md, wiki/meta/2026-04-14-claude-seo-v190-session.md
- category: derived
- rationale: v1.9.0 state with skill counts and Pro Hub Challenge integration.
### D16
- query: Does Ar9av's obsidian-wiki support multi-agent deployment and how?
- correct: wiki/entities/Ar9av-obsidian-wiki.md
- relevant: wiki/comparisons/claude-obsidian-ecosystem.md, wiki/concepts/cherry-picks.md
- category: derived
- rationale: setup.sh bootstrap matrix across multiple agents and delta tracking manifest.
### D17
- query: What does the /adopt command in ballred's PKM system do?
- correct: wiki/entities/ballred-obsidian-claude-pkm.md
- relevant: wiki/concepts/cherry-picks.md, wiki/comparisons/claude-obsidian-ecosystem.md
- category: derived
- rationale: Vault analysis and pattern detection for PARA, Zettelkasten, LYT migration.
### D18
- query: What official Obsidian skills does kepano publish and which is most token-efficient?
- correct: wiki/entities/kepano-obsidian-skills.md
- relevant: wiki/concepts/cherry-picks.md, wiki/entities/Claudian-YishenTu.md
- category: derived
- rationale: obsidian-markdown, obsidian-bases, defuddle, and defuddle's 40-60% token reduction.
### D19
- query: What are the three query depths in rvk7895's LLM knowledge base system?
- correct: wiki/entities/rvk7895-llm-knowledge-bases.md
- relevant: wiki/concepts/cherry-picks.md, wiki/comparisons/claude-obsidian-ecosystem.md
- category: derived
- rationale: Quick, Standard, Deep modes with output formats.
### D20
- query: How does Nexus MCP for Obsidian store workspace memory and is it Obsidian Sync compatible?
- correct: wiki/entities/Nexus-claudesidian-mcp.md
- relevant: wiki/comparisons/claude-obsidian-ecosystem.md
- category: derived
- rationale: JSONL storage and Sync auto-inclusion.
### D21
- query: What makes Claudian's inline edit feature best-in-class compared to other Obsidian AI plugins?
- correct: wiki/entities/Claudian-YishenTu.md
- relevant: wiki/comparisons/claude-obsidian-ecosystem.md
- category: derived
- rationale: Word-level diff preview and one-click apply with Plan Mode support.
### D22
- query: Between claude-obsidian and other projects, who has the hot cache mechanism?
- correct: wiki/comparisons/claude-obsidian-ecosystem.md
- relevant: wiki/concepts/Hot Cache.md, wiki/index.md
- category: derived
- rationale: Feature matrix shows claude-obsidian is unique in session context caching.
### D23
- query: When was the first real fold committed to the vault and what was its fold_id?
- correct: wiki/folds/fold-k3-from-2026-04-23-to-2026-04-24-n8.md
- relevant: wiki/log.md, wiki/hot.md, wiki/concepts/DragonScale Memory.md
- category: derived
- rationale: Fold metadata with exact creation date and 8-entry batch documentation.
### D24
- query: What pages were created after the boundary-first autoresearch frontier pass?
- correct: wiki/log.md
- relevant: wiki/concepts/Persistent Wiki Artifact.md, wiki/concepts/Source-First Synthesis.md, wiki/concepts/Query-Time Retrieval.md
- category: derived
- rationale: Log entry for 2026-04-24 M4 run explicitly lists the three new concept pages filed.
### D25
- query: What is a Persistent Wiki Artifact and how does it differ from ephemeral chat turns?
- correct: wiki/concepts/Persistent Wiki Artifact.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/concepts/Source-First Synthesis.md
- category: derived
- rationale: Explicit definition of durable memory object with frontmatter, title, wikilinks, and provenance.
---
## Hard Queries (25)
### H1
- query: How does the exponential compaction operator summarize batch entries?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md
- category: synonym
- rationale: "Fold operator" and "rollup" are interchangeable; query uses LSM terminology instead of dragon-curve naming.
### H2
- query: What stable identifiers help page references survive renames in prompt-cache workloads?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md, wiki/hot.md
- category: synonym
- rationale: Deterministic addresses (c-NNNNNN format) are the answer; query uses prompt-cache context instead.
### H3
- query: How does the semantic tiling mechanism detect and flag duplicate or near-duplicate pages?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md, wiki/hot.md
- category: synonym
- rationale: Mechanism 3 performs dedup via cosine similarity; query uses "near-duplicate" instead of "semantic tiling."
### H4
- query: When user asks /autoresearch without a topic, which pages are candidates and how are they scored?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md, wiki/hot.md
- category: synonym
- rationale: Boundary-first autoresearch (Mechanism 4) surfaces frontier pages; query uses "autoresearch no-topic" instead.
### H5
- query: How should the wiki layer stay connected to raw source material without replacing source content?
- correct: wiki/concepts/Source-First Synthesis.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/concepts/Persistent Wiki Artifact.md
- category: synonym
- rationale: Source-first synthesis is the provenance rule; query asks for the principle without using the term.
### H6
- query: When building a wiki versus RAG, how does the cost structure differ in maintenance, infrastructure, and long-term knowledge value?
- correct: wiki/concepts/LLM Wiki Pattern.md, wiki/comparisons/Wiki vs RAG.md, wiki/concepts/Compounding Knowledge.md
- relevant: wiki/overview.md
- category: cross-page
- rationale: Spans three concepts: architecture table, comparison table, and compounding mechanics.
### H7
- query: What does the wiki-fold skill output in dry-run mode and how does it create child references?
- correct: wiki/concepts/DragonScale Memory.md, wiki/log.md
- relevant: wiki/hot.md
- category: cross-page
- rationale: Mechanism 1 spec + dry-run artifact from 2026-04-24 Phase 1 log entry cross-reference.
### H8
- query: How would adding URL ingestion and web cleaning together reduce token usage during ingest?
- correct: wiki/concepts/cherry-picks.md, wiki/entities/kepano-obsidian-skills.md
- relevant: wiki/getting-started.md
- category: cross-page
- rationale: Combining cherry-pick #1 (URL ingest) and defuddle (40-60% token reduction) from two sources.
### H9
- query: Which project has the best auto-commit hook and how did that feature get integrated into Claude SEO?
- correct: wiki/entities/ballred-obsidian-claude-pkm.md, wiki/entities/Claude SEO.md, wiki/log.md
- relevant: wiki/comparisons/claude-obsidian-ecosystem.md
- category: cross-page
- rationale: ballred has PostToolUse auto-commit; Claude SEO v1.9.0 release cites integration patterns.
### H10
- query: How would you audit a page for SERP alignment, topic cannibalization risk, and performance regressions together?
- correct: wiki/concepts/Search Experience Optimization.md, wiki/concepts/Semantic Topic Clustering.md, wiki/concepts/SEO Drift Monitoring.md
- relevant: wiki/entities/Claude SEO.md, wiki/log.md
- category: cross-page
- rationale: Three separate v1.9.0 features; query asks for integrated workflow across all three.
### H11
- query: What were the six test stages and did all mechanisms pass validation before v1.6.0 shipped?
- correct: wiki/log.md, wiki/hot.md
- relevant: wiki/concepts/DragonScale Memory.md
- category: cross-page
- rationale: 2026-04-24 end-to-end validation pass entry lists T0-T6; hot.md confirms all four mechanisms validated.
### H12
- query: Why does the LLM Wiki pattern avoid re-querying and re-assembling the same sources every time?
- correct: wiki/concepts/Query-Time Retrieval.md, wiki/concepts/Persistent Wiki Artifact.md, wiki/concepts/Source-First Synthesis.md
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/concepts/Compounding Knowledge.md
- category: cross-page
- rationale: Spans three pages: RAG baseline definition + durable memory object + synthesis discipline.
### H13
- query: What are two independent ways to embed the LLM Wiki pattern in different editor environments?
- correct: wiki/entities/Ar9av-obsidian-wiki.md, wiki/entities/Claudian-YishenTu.md
- relevant: wiki/comparisons/claude-obsidian-ecosystem.md
- category: cross-page
- rationale: Ar9av setup.sh for multiple agents; Claudian native TypeScript plugin; both different deployment models.
### H14
- query: How could you avoid re-processing unchanged sources when integrating community submissions?
- correct: wiki/concepts/cherry-picks.md, wiki/concepts/Pro Hub Challenge.md
- relevant: wiki/log.md
- category: cross-page
- rationale: Delta tracking manifest solves re-ingest problem; integration pattern in Pro Hub workflow.
### H15
- query: What is the most direct way to add defuddle to claude-obsidian's current ingest pipeline?
- correct: wiki/entities/kepano-obsidian-skills.md, wiki/concepts/cherry-picks.md
- relevant: wiki/getting-started.md
- category: cross-page
- rationale: Cherry-pick #3 + getting-started ingest flow both discussed; requires both for full picture.
### H16
- query: Where can I find Karpathy's original description of the wiki pattern?
- correct: wiki/concepts/Persistent Wiki Artifact.md, wiki/concepts/Source-First Synthesis.md, wiki/entities/Andrej Karpathy.md
- relevant: wiki/concepts/LLM Wiki Pattern.md
- category: partial-recall
- rationale: Multiple pages cite Karpathy gist; user remembers "gist" + "Karpathy."
### H17
- query: What was inspired by dragon curves and what problem does it solve?
- correct: wiki/concepts/DragonScale Memory.md
- relevant: wiki/log.md
- category: partial-recall
- rationale: User recalls dragon analogy but not "DragonScale"; wants to understand fold operator.
### H18
- query: What is the ~500-word file that gets updated at the end of every session?
- correct: wiki/concepts/Hot Cache.md
- relevant: wiki/getting-started.md, wiki/overview.md, wiki/hot.md
- category: partial-recall
- rationale: Exact description matches; user remembers fragment but not exact terminology.
### H19
- query: Which community competition paid out Claude Credits and who won first?
- correct: wiki/concepts/Pro Hub Challenge.md
- relevant: wiki/entities/Claude SEO.md
- category: partial-recall
- rationale: User remembers community challenge and winners but not the name.
### H20
- query: How many projects does the wiki track as competitors or adjacent to claude-obsidian?
- correct: wiki/comparisons/claude-obsidian-ecosystem.md
- relevant: wiki/concepts/cherry-picks.md
- category: partial-recall
- rationale: User remembers ecosystem matrix but not exact page; queries for count of projects.
### H21
- query: How does the wiki pattern use blockchain or distributed ledger technology for vault consensus?
- correct: null
- relevant: wiki/concepts/DragonScale Memory.md
- category: negative
- rationale: Wiki does not discuss blockchain; DragonScale addresses are creation-order counter, not DLT.
### H22
- query: What CRDT algorithm does the vault use for simultaneous multi-user editing?
- correct: null
- relevant: wiki/hot.md, wiki/concepts/DragonScale Memory.md
- category: negative
- rationale: No CRDT discussion; v1.7 mentions wiki-lock.sh for multi-writer safety (locking, not CRDTs).
### H23
- query: Can I build an LLM wiki without installing Obsidian as a desktop application?
- correct: null
- relevant: wiki/concepts/LLM Wiki Pattern.md, wiki/getting-started.md
- category: negative
- rationale: Pattern is agnostic but this vault uses Obsidian. No Obsidian-free mode documented.
### H24
- query: How do you customize the semantic embedding model weights for better tiling accuracy on your domain?
- correct: null
- relevant: wiki/concepts/DragonScale Memory.md, wiki/log.md
- category: negative
- rationale: Mechanism 3 uses locked ollama nomic-embed-text; no fine-tuning support documented.
### H25
- query: Does the vault have CI/CD pipeline to automatically ingest new .raw files on every push?
- correct: null
- relevant: wiki/log.md, wiki/hot.md
- category: negative
- rationale: No GitHub Actions / CI-CD / automated ingest documented. Auto-commit hook exists but not scheduled CI.
---
## Benchmark Notes
**Coverage**: 47 wiki pages, ~50 queries → roughly 1 query per page on average; spread covers concepts, entities, comparisons, meta, folds, sources.
**Balance**: 25 derived (natural questions) + 5 synonym + 10 cross-page + 5 partial-recall + 5 negative.
**Targets** (rough expectation, not a gate):
- v1.6 baseline top-1: ~50-65% on derived, much lower on hard
- v1.7 hybrid top-1: ~75-90% on derived, ~50-70% on hard
- Plan §7 ship gate (from v1.7 implementation plan): ≥30% reduction in "wrong page cited" errors. Verify by comparing the percentage-points improvement on top-1 across all 50 queries.
wiki/meta/tiling-report-2026-04-24.md
-32
View File
@@ -1,32 +0,0 @@
# Semantic Tiling Report
- generated: 2026-04-24T09:20:59Z
- model: nomic-embed-text
- ollama_url: http://127.0.0.1:11434
- thresholds: error>=0.9, review=0.8-0.9
- calibrated: False (using uncalibrated defaults)
- pages scanned: 41; embedded: 21; skipped: 20
- skipped reasons: embed_error=1, excluded filename=9, under wiki/meta/=10
- cache hits: 0; recomputed: 21; orphans pruned: 0
## Errors (similarity >= 0.9)
- none
## Review (0.8 <= similarity < 0.9)
- `0.8822` wiki/concepts/Compounding Knowledge.md -- wiki/concepts/LLM Wiki Pattern.md
- `0.8729` wiki/concepts/LLM Wiki Pattern.md -- wiki/questions/How does the LLM Wiki pattern work.md
- `0.8681` wiki/comparisons/claude-obsidian-ecosystem.md -- wiki/sources/claude-obsidian-ecosystem-research.md
- `0.8594` wiki/concepts/cherry-picks.md -- wiki/entities/Ar9av-obsidian-wiki.md
- `0.8401` wiki/concepts/Compounding Knowledge.md -- wiki/questions/How does the LLM Wiki pattern work.md
- `0.8400` wiki/entities/Claudian-YishenTu.md -- wiki/entities/Nexus-claudesidian-mcp.md
- `0.8343` wiki/concepts/LLM Wiki Pattern.md -- wiki/entities/Andrej Karpathy.md
- `0.8318` wiki/concepts/cherry-picks.md -- wiki/sources/claude-obsidian-ecosystem-research.md
- `0.8244` wiki/comparisons/claude-obsidian-ecosystem.md -- wiki/concepts/cherry-picks.md
- `0.8229` wiki/entities/kepano-obsidian-skills.md -- wiki/sources/claude-obsidian-ecosystem-research.md
- `0.8171` wiki/entities/ballred-obsidian-claude-pkm.md -- wiki/sources/claude-obsidian-ecosystem-research.md
- `0.8067` wiki/concepts/cherry-picks.md -- wiki/entities/kepano-obsidian-skills.md
- `0.8064` wiki/entities/Ar9av-obsidian-wiki.md -- wiki/entities/kepano-obsidian-skills.md
- `0.8052` wiki/concepts/LLM Wiki Pattern.md -- wiki/entities/rvk7895-llm-knowledge-bases.md
- `0.8040` wiki/entities/Andrej Karpathy.md -- wiki/entities/rvk7895-llm-knowledge-bases.md
wiki/meta/welcome-canvas.gif
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 585 KiB

wiki/meta/wiki-graph-grow.gif
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 285 KiB

wiki/meta/workflow-loop.gif
BIN
View File
Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 227 KiB

Some files were not shown because too many files have changed in this diff Show More