feat: add home-assistant-dashboard-conventions skill + update multiple skills

- New: smart-home/home-assistant-dashboard-conventions (Mushroom cards, view tabs, no Bubble Cards)
- Updated: rke2, ceph, galera, proxmox, brainstorming, compound-learning, 1password-cli, smart-home-automation skills
- New references: ceph-cluster-administration, docker-volume-forensics, ceph-crush-weight, ceph-ec-mixed-size
This commit is contained in:
Debian
2026-07-14 18:35:16 +00:00
parent e9cc106625
commit 01bd921ced
37 changed files with 6133 additions and 126 deletions
@@ -120,6 +120,8 @@ During exploration, if the conversation converges on "should we adopt/switch to/
- **Load the skill BEFORE generating brainstorming content.** When a user says "brainstorming first", "let's brainstorm", or similar, load this skill IMMEDIATELY and follow its structured process (one question at a time, multiple choice, incremental validation). Do NOT dump a full ad-hoc analysis first and then load the skill afterward — the structured process IS the value, not the ideas themselves. The user asking for the skill after you've already brainstormed is a correction signal.
- **Load the skill BEFORE writing any code or manifests.** Even if the user doesn't explicitly say "brainstorming", any task that involves building, migrating, or creating something new should trigger this skill FIRST. A user redirecting you from `execute_code` / manifest writing to "use the ce_* skills, starting with brainstorming" is a STRONG correction signal — they expected the structured design process, not premature implementation. This applies to infrastructure migrations, feature development, and configuration changes alike. Even if manifests seem straightforward, the structured exploration reveals design decisions (backup strategy, token handling, archive structure, cutover approach) that would otherwise be discovered too late. When corrected, STOP implementation immediately, delete any prematurely-created files, load the brainstorming skill, and start from Step 1. The full Compound Engineering chain is: brainstorming → writing-plans → (subagent-driven-development | manual execution). Do NOT skip to execution even after the design is approved — produce the implementation plan first via the `writing-plans` skill.
- **One question at a time** — don't overwhelm
- **Multiple choice preferred** — easier to answer than open-ended
- **Incremental validation** — present design, get approval before moving on
@@ -234,6 +234,9 @@ Trigger headless mode when invoked from another skill (e.g., `subagent-driven-de
- **Don't forget the tags** — untagged docs are unfindable
- **Write for the next agent, not for yourself** — the reader has zero context
- **Check Hindsight daemon health BEFORE batch retain** — Phase 4.5 says to check `curl -s http://127.0.0.1:9177/health` first, but it's tempting to fire multiple `hindsight_retain` calls in parallel for efficiency. If the daemon is down, ALL calls fail and trigger loop-warning penalties. Always: one health check → then batch retains. The `docs/solutions/` files are sufficient alone if Hindsight is unavailable.
- **Environment misclassification** — When documenting infra topics, verify which environment a component belongs to BEFORE writing. The user runs a self-hosted Homelab (Ceph, Proxmox, K8s, 1Password, Galera, HA, Monitoring) AND separate noris network AG infrastructure (S3, OpenStack/NSC, ai.noris.de, PPTX, EU AI Act). The `infra-compound-learning` repo is **Noris-only and shareable with colleagues** — Homelab learnings must NOT be committed there. They stay in the local working dir `/home/debian/docs/solutions/`. Tag every doc with `noris` or `homelab` as the first tag. When unsure: it's probably Homelab.
- **Workload vs. infrastructure confusion (CORRECTED BY USER 3 TIMES — TOP RECURRING MISTAKE)** — When you deploy an application (PBS, Grafana, nginx) on a platform (OpenStack, K8s), the compound learning is about the **platform gotchas**, NOT the application setup. "How to install PBS on OpenStack" is a runbook, not a learning. "AZ-Mismatch: volumes and VMs must share an AZ or boot fails silently" is a learning. Strip the application-specific steps (install commands, config files, port numbers, retention policies, application config) and keep only the infrastructure insight. If the doc reads like a tutorial for application X, reframe it as a platform learning that happens to mention X as context. **MANDATORY SELF-CHECK before committing any infra doc**: "Would this learning still apply if the application were swapped?" → If yes: it's infrastructure. → If no: it's a runbook, not a learning. The user has corrected this pattern THREE TIMES now — do NOT write "Setup of X on Y" docs. Write "Y deployment gotchas (learned while deploying X)". When in doubt: the application is ALWAYS just context, never the subject of the learning.
- **Concept-first before execution (CORRECTED BY USER 2026-07-14)** — When tasked with an infrastructure migration or complex deployment, the user expects a conceptual plan (phases, dependencies, risks, key insights) BEFORE any manifests are written or commands executed. Jumping directly to `execute_code` or `terminal` without presenting the strategy first was explicitly corrected: "nicht nur execute_code sondern schon die Konzeption". This applies to ALL non-trivial infrastructure work: migrations, new service deployments, architectural changes. Present the concept, get implicit or explicit buy-in, THEN execute. Simple status checks and read-only operations do NOT require this — only tasks that modify state.
## Integration with Other Skills
@@ -257,6 +260,34 @@ Use Hermes tools throughout:
- `hindsight_retain` — sync solution summary to Hindsight (Phase 4.5) for semantic discoverability
- `hindsight_recall` — used by Grounding Scans in other skills to find this solution later
## Dedicated Repositories
For domains with high learning density, a dedicated Gitea repository replaces ad-hoc `docs/solutions/` in the project root:
### noris-compound-learning (Noris-only, shareable)
- **Repo**: [git.familie-schoen.com/dominik/noris-compound-learning](http://git.familie-schoen.com/dominik/noris-compound-learning)
- **Local clone**: `/home/debian/infra-compound-learning/` (local dir name kept as-is; Gitea repo was renamed to `noris-compound-learning` via API — `git remote set-url origin` updated to match)
- **Gitea API rename**: `curl -X PATCH "http://<gitea>/api/v1/repos/<owner>/<old-name>" -H "Authorization: token <token>" -H "Content-Type: application/json" -d '{"name": "new-name"}'` — renames repo in place, preserves all history/issues. Then `git remote set-url origin <new-url>` locally. Update all references in README/AGENTS/INDEX files and commit.
- **Gitea token extraction**: Token is embedded in the git remote URL (`git remote -v` shows `http://user:TOKEN@host:port/...`). Extract via regex if `op --reveal` fails or the token isn't in 1Password.
- **Scope**: **Noris network AG only** — shareable with colleagues, no private homelab data
- **Domains**: S3/Object Storage, OpenStack/NSC (VM deployment, flavours, AZs, volumes, networking), ai.noris.de API, Noris PPTX, EU AI Act Compliance
- **Structure**: `docs/solutions/{type}/`, `concepts/CONCEPTS.md`, `skills/INDEX.md`, `templates/`, `references/`
- **AGENTS.md**: Present — instructions for AI agents working in the repo
- **Convention**: Every doc MUST start tags with `noris`, `environment: noris` in frontmatter
**Grounding Scan for infra topics** should search BOTH locations:
```python
# 1. Local working dir — Homelab learnings (private, not in the repo)
search_files("keywords", path="/home/debian/docs/solutions/")
# 2. Dedicated infra repo — Noris learnings (versioned, shareable)
search_files("keywords", path="/home/debian/infra-compound-learning/docs/solutions/") # noris-compound-learning repo (local dir name unchanged)
```
**Routing rule**: Homelab learnings (Ceph, PVE, K8s, Galera, HA, Monitoring, 1P) stay in the local working dir only. Noris learnings go to the noris-compound-learning repo. Never mix the two in the same repo.
## Remember
```
@@ -267,6 +298,7 @@ Overlap check before writing
CONCEPTS.md for vocabulary
Hindsight sync for semantic findability
Self-improvement routing closes the loop
Dedicated repos for high-density domains
```
**Knowledge compounds — but only if you capture it. And the strongest compound is fixing the system itself.**
@@ -275,3 +307,4 @@ Self-improvement routing closes the loop
- `references/self-improvement-loop.md` — Full architecture diagram of the closed-loop system: compound-learning → Hindsight → meta-memory cronjobs → self-improvement routing → next-session grounding scans.
- `references/retrospective-session-analysis.md` — Technique for mining past session logs from `state.db` (SQLite) to retroactively capture learnings that weren't documented at the time. Includes SQL schema reference and classification criteria.
- `references/ai-noris-de-model-catalog.md` — Full model catalog from ai.noris.de `/v1/models` API (vLLM + Anthropic models, context sizes, pricing, capabilities). Retrieved 2026-07-13.
@@ -0,0 +1,49 @@
# ai.noris.de Model Catalog (from /v1/models API)
Retrieved 2026-07-13 via `GET https://ai.noris.de/v1/models` with Bearer auth.
## vllm/release/ Models (free for noris employees)
| Model ID | Context | Max Input | Max Output | Type | Vision |
|----------|---------|-----------|------------|------|--------|
| `vllm/release/glm-5-2` | 1,048,576 (1M) | 1M | 1M | General LLM | ❌ |
| `vllm/release/gemma-4-31b-it` | 131,072 (128K) | 128K | 128K | Vision LLM | ✅ |
| `vllm/release/gpt-oss-120b` | 131,072 (128K) | 128K | 128K | General LLM | ❌ |
| `vllm/release/qwen3.6-27b` | 262,144 (256K) | 256K | 8,192 (8K) | Text LLM | ❌ |
| `vllm/release/qwen3.5-122b-a10b` | — | — | — | MoE Vision | ⚠️ poor quality |
| `vllm/release/qwen3.6-35b-a3b` | — | — | — | MoE LLM | ❌ |
| `vllm/release/harrier-oss-v1-0.6b` | 8,192 (8K) | 8K | — | Embedding | N/A |
| `vllm/release/qwen3-embedding-8b` | — | — | — | Embedding | N/A |
| `vllm/release/bge-reranker-v2-m3` | 32,000 (32K) | 32K | — | Reranker | N/A |
| `vllm/release/jina-reranker-v2-base-multilingual` | — | — | — | Reranker | N/A |
Some models (qwen3.5-122b-a10b, qwen3.6-35b-a3b, harrier-oss-v1-0.6b, qwen3-embedding-8b, jina-reranker-v2) return no context/pricing fields — only `id` + `owned_by`.
## Anthropic Models (costs apply for noris employees)
| Model ID | Context | Max Output | Prompt/1K | Completion/1K |
|----------|---------|------------|-----------|---------------|
| `anthropic/claude-fable-5` | 1M | 128K | $0.010 | $0.050 |
| `anthropic/claude-opus-4-8` | 1M | 128K | $0.005 | $0.025 |
| `anthropic/claude-opus-4-7` | 1M | 128K | $0.005 | $0.025 |
| `anthropic/claude-opus-4-6` | 1M | 128K | $0.030 | $0.150 |
| `anthropic/claude-opus-4-5-20251101` | 200K | 64K | $0.005 | $0.025 |
| `anthropic/claude-opus-4-1-20250805` | 200K | 32K | $0.015 | $0.075 |
| `anthropic/claude-sonnet-5` | 1M | 128K | $0.002 | $0.010 |
| `anthropic/claude-sonnet-4-6` | 1M | 128K | $0.003 | $0.015 |
| `anthropic/claude-sonnet-4-5-20250929` | 200K | 64K | $0.003 | $0.015 |
| `anthropic/claude-haiku-4-5-20251001` | 200K | 64K | $0.001 | $0.005 |
## Key Facts
- **Model prefix `vllm/release/` is mandatory** — bare names (e.g. `glm-5-2`) fail
- **API is OpenAI-compatible**: `/v1/chat/completions`, `/v1/embeddings`
- **Base URL**: `https://ai.noris.de` — Docs: `https://ai.noris.de/docs/`
- **Auth**: Bearer token (API key from Hermes config or noris portal)
- **13 Anthropic models** available alongside vLLM models via the same API
- Pricing fields in API response are for external customers — noris employees don't pay for `vllm/release/` models
- **Anthropic models cost money even for noris employees** — only `vllm/release/` models are free internally
- **glm-5-2** has 1M context — largest context window in the vLLM lineup
- **qwen3.6-27b** has only 8K max output despite 256K input — watch this asymmetry
- Embedding alternatives: `harrier-oss-v1-0.6b` (8K ctx) and `qwen3-embedding-8b` (unknown ctx)
- Two rerankers available: `bge-reranker-v2-m3` (32K) and `jina-reranker-v2-base-multilingual`