Compare commits

..
Author SHA1 Message Date
Frank 879d200bc1 back-merge: main -> develop after PR #5 (status line custom segments)
Supersedes c4cf53f/5d7314e (broken: first took develop's tree wholesale,
second merged against a base that already contained main). Three genuine
conflicts resolved in main's favor: develop's models.yml refactors
predate the October callsign-rename cutover; the dank-user memory buckets
are superseded by main's learn output.
2026-10-18 01:11:38 -07:00
Frank dc046a7cb0 refactor: split providers back to dankserver + dankclaw, keep model names 2026-08-28 14:25:27 -07:00
Frank 3b16ac3984 refactor: consolidate models under frankdank.cloud, shorten display names 2026-08-28 13:33:04 -07:00
Frank 1a7c687cb4 chore: live memory update — quadlet gotchas for Anubis rollout (verified live) 2026-08-28 12:24:51 -07:00
Frank 6324d54168 chore: live memory update — session state (Gitea Projects disabled, v1.0.0 shipped via git-flow) 2026-08-28 08:13:50 -07:00
Frank a986d77449 back-merge: main -> develop after v1.0.0 release 2026-08-28 07:58:36 -07:00
21 changed files with 199 additions and 353 deletions

No files matched your search

+14 -21
View File
@@ -13,32 +13,26 @@ with YAML frontmatter, spec at `omp-docs/references/okf-spec.md`).
(`dank/command-center` on the Dankclaw instance). There is no staging copy:
**the checkout is the deployment.** Branch switches swap live config files out
from under the running agent — keep feature branches short-lived, and never end
a work session checked out on anything but `main`.
a work session checked out on anything but `develop` or `main`.
- Contents that belong here: `AGENTS.md`, `omp-docs/` (knowledge base),
`scripts/` (small system utilities), `agent/` + `plugins/` (harness config and
plugin manifests). Everything else under this directory is runtime state and is
gitignored on principle — see `.gitignore`. History must mean "the configuration
changed", not "the agent breathed".
## Trunk-based SDLC (since 2026-10-18; replaces the old git-flow regime)
## Git-flow SDLC (full flow, from day one)
- `main` is the only long-lived branch. Frank is the only dev; `develop` and the
release-branch ceremony are retired — no `develop`, no back-merges, no
`release/X.Y.Z` branches.
- **Before every work item: fetch and branch off the freshest `origin/main`.**
If main moves under you, merge it into your branch (never rebase — Frank
dislikes the history rewrite).
- Work item = Gitea issue on `dank/command-center` (Gitea at 192.168.0.143:3000,
owner `dank`). Small fixes may go straight to a branch; anything with more than
one moving part gets an issue first.
- Branch naming: `<type>/<issue#>-<slug>`, type ∈ feat|fix|docs|chore.
- **Pull requests target `main` directly.** Merge with `--no-ff` so feature arcs
stay visible in history. **Never merge a PR without an explicit OK from Frank.**
- **The moment a PR is open, open it in Frank's browser** — `xdg-open <PR-URL>`
lands a tab in his Firefox; never make him hunt for it in Gitea.
- Releases: tag `vX.Y.Z` straight on `main` after verifying; tags are the deploy
markers every other machine pulls to. Hotfixes are ordinary branches off the
tag you are fixing forward from.
Release cuts: `release/X.Y.Z` from `develop`; hotfixes: `hotfix/<slug>` from `main`.
- **Merge, never rebase**, when updating a branch against a moved main — Frank
dislikes the history rewrite. **Never merge a PR without an explicit OK from Frank.**
- Merge into `develop` with `--no-ff` so feature arcs stay visible in history.
- Releases: cut `release/X.Y.Z` from `develop`, verify, merge to `main`, tag
`vX.Y.Z`, back-merge `main` into `develop`. Tags are the deploy markers every
other machine pulls to.
- Trash convention: never `rm` anything user-authored — move it to `.AGENTTRASH/`
(gitignored). Deletion is a pruning session with Frank present.
@@ -77,8 +71,8 @@ secret in every agent's context window on every machine that pulls this repo.
| box | role | GPU | notes |
|-----|------|-----|-------|
| Dev workstation | client box, never runs inference | laptop iGPU + dGPU (non-unified) | mainline llama.cpp at `~/GitPackages/llama.cpp/build/bin/`; this repo lives here at `~/.omp` |
| Dankclaw | bench target, secondary models + service stack | Strix Halo APU (**unified memory**) + RTX 3090 (moved over from Dankserver 2026-09) | prod services `frank-dragoon` (halogen-flash-server, :7770, iGPU) and `frank-zealot` (llama.cpp PrismML fork, :7771, 3090); runbooks in the serverAppConfigs vault (`~/Projects/serverAppConfig/serverAppConfigs-docs/LLM/`); ssh: `ssh dankclaw` |
| Dankserver | main-model box | 2× Radeon AI PRO R9700 — non-unified (was RTX 3090 until 2026-09) | runs `frank-archon` (radiance, TP=2, :7770) — **this repo's operator session runs on it**; ssh: `ssh dankserver` |
| Dankclaw | bench target, runs the large serving model | Strix Halo APU — **unified memory** | ROCmFPX fork at `~/GitPackages/ROCmFPX/build-qwen38/bin/`; prod service `frank-default-large`, port 7770; ssh: `ssh dankclaw` |
| Dankserver | FreeToken box | RTX 3090 dGPU — non-unified | runs `frank-default-small`; ssh: `ssh dankserver` |
## Environment gotchas
@@ -90,10 +84,9 @@ secret in every agent's context window on every machine that pulls this repo.
- SSH into both servers is BatchMode-capable from here:
`ssh -o BatchMode=yes dankclaw '<read-only command>'` — read-only probes are
always allowed; state changes on remote boxes are not, without a per-run OK.
- `frank-archon` (Dankserver), `frank-dragoon`, and `frank-zealot` (Dankclaw)
are **production services** shared with this repo's operator: never stop,
mask, or restart them (or any production service on any box) without an
explicit, current, per-run OK from Frank.
- `frank-default-large` on Dankclaw is a **production service** shared with this
repo's operator: never stop, mask, or restart it (or any production service on
any box) without an explicit, current, per-run OK from Frank.
## File-organization doctrine (why this repo stays readable)
+1 -1
View File
@@ -141,7 +141,7 @@ display:
showTokenUsage: true
task:
showResolvedModelBadge: true
maxConcurrency: 3
maxConcurrency: 2
agentModelOverrides:
designer: llamacpp (dankclaw-3090)/frank-zealot
librarian: llamacpp (dankclaw-3090)/frank-zealot
+3 -5
View File
@@ -10,7 +10,7 @@ Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/setup-matt-pocock-skills`.
## Process
@@ -26,14 +26,14 @@ Before going further, confirm the fixed point resolves (`git rev-parse <fixed-po
Look for the originating spec, in this order:
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in the tracker doc.
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.
2. A path the user passed as an argument.
3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
### 3. Identify the standards sources
Search the repo for every file that documents how code should be written. When `CODING_STANDARDS.md` or `CONTRIBUTING.md` exists, it must be on the list.
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below: a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
@@ -57,8 +57,6 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
### 4. Spawn both sub-agents in parallel
Issue both sub-agent calls together, in the foreground, and aggregate the reports they return.
**Standards sub-agent prompt** should include:
- The full diff command and commit list.
+2 -2
View File
@@ -7,7 +7,7 @@ description: Diagnosis loop for hard bugs and performance regressions. Use when
A discipline for hard bugs. Skip phases only when explicitly justified.
When exploring the codebase, read `GLOSSARY.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
## Redact
@@ -122,7 +122,7 @@ A correct seam is one where the test exercises the **real bug pattern** as it oc
If a correct seam exists:
1. Turn the minimised repro into a failing test at that seam.
2. Watch it fail. If you forced the red by mutating code or a fixture, `diff` against a pristine copy to prove the mutation landed before you trust it.
2. Watch it fail.
3. Apply the fix.
4. Watch it pass.
5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
-2
View File
@@ -21,8 +21,6 @@ Format a round like so:
➡️ <your recommended answer>
```
Word each question so "yes" accepts your recommended answer.
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+1 -1
View File
@@ -5,7 +5,7 @@ argument-hint: "What will the next session be used for?"
disable-model-invocation: true
---
Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS (`$TMPDIR`, else `/tmp`; `%TEMP%` on Windows) - not the current workspace.
Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
Include a "suggested skills" section in the document, naming which skills the next agent should call the Skill tool for.
+2 -4
View File
@@ -6,12 +6,10 @@ disable-model-invocation: true
Implement the work described by the user in the spec or tickets.
If the user passes a ticket reference, fetch it from the issue tracker and state its title before starting. If the reference is ambiguous, ask.
Call the Skill tool with "tdd" where possible, at pre-agreed seams.
Use /tdd where possible, at pre-agreed seams.
Run typechecking regularly, single test files regularly, and the full test suite once at the end.
Once done, call the Skill tool with "code-review" to review the work.
Once done, use /code-review to review the work.
Commit your work to the current branch.
+2 -2
View File
@@ -7,7 +7,7 @@ description: Test-driven development. Use when the user wants to build features
TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.
When exploring the codebase, read `GLOSSARY.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
## What a good test is
@@ -21,7 +21,7 @@ A **seam** is the public boundary you test at: the interface where you observe b
**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
Ask: "What's the public interface, and which seams should we test?" Give each proposed seam a one-line note on what it catches and what it misses.
Ask: "What's the public interface, and which seams should we test?"
When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), call the Skill tool with "codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
+2 -2
View File
@@ -9,7 +9,7 @@ The user has asked you to teach them something. This is a stateful request - the
## Teaching Workspace
Treat the current directory as a teaching workspace. Workspace paths (`./lessons/` and the rest) resolve from the directory `/teach` was run in; only the `*-FORMAT.md` links resolve from this skill's folder. The state of their learning is captured in this directory in several files:
Treat the current directory as a teaching workspace. The state of their learning is captured in this directory in several files:
- `MISSION.md`: A document capturing the _reason_ the user is interested in the topic. This should be used to ground all teaching. Use the format in [MISSION-FORMAT.md](./MISSION-FORMAT.md).
- `./reference/*.html`: A directory of reference materials. These are the compressed learnings from the lessons - cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
@@ -107,7 +107,7 @@ For skill acquisition, difficulty is the tool. Effortful retrieval is what build
Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
For quizzes, each answer should be exactly the same number of words (and characters, if possible). Vary which position holds the correct answer across questions. Don't give the user any clues about the answer through formatting or order.
For quizzes, each answer should be exactly the same number of words (and characters, if possible). Don't give the user any clues about the answer through formatting.
## Acquiring Wisdom
+2 -8
View File
@@ -1,18 +1,12 @@
# Core Documentation
These files define the structural conventions that govern the agent system itself. They are the grammar rules — boring until you break them, then devastating.
> **Archive note (2026-10-18).** The settings pages (`settings.md`, `settings.json`)
> capture the retired **pi** harness configuration (`frank-default-*` endpoints,
> RTX 3090-era hardware) and are historical records. The live config is
> `agent/config.yml` + `agent/models.yml` in this repo; current fleet endpoints
> are on [System hosts](/system/index.md). The AGENTS.md format pages remain current.
These files define the structural conventions that govern the pi agent system itself. They are the grammar rules — boring until you break them, then devastating.
## Concept Files
* [AGENTS.md Format Specification](agents-md-format.md) — Canonical structure and conventions for the system-level instruction file that governs agent behavior.
* [AGENTS.md Index](index-doc.md) — Overview of the cached tool documentation system and how to add new entries.
* [Pi Settings System](settings.md) — pi-era `settings.json` record (archive): providers, models, packages, subagent overrides.
* [Pi Settings System](settings.md) — Current system configuration: providers, models, packages, subagent overrides, and runtime options.
## Change Tracking
+1 -29
View File
@@ -11,39 +11,11 @@ timestamp: 2026-08-28
# Bundle Change Log
## 2026-10-18 — Fleet law: filed PRs open in Frank's browser immediately
Both repos' git rules now require it: the moment a PR is opened, `xdg-open <PR-URL>` drops a Firefox tab on the workstation (AGENTS.md § Trunk-based SDLC here; § Git Workflow step 6 in `dank/serverAppConfigs`, riding their PR #6 branch).
## 2026-10-18 — Trunk law: extension route closed unmerged; direct repo alignment instead
Built and live-verified a cwd-scoped `before_agent_start` extension (quote probes: fires under `~/Projects`, silent elsewhere; kept as `.AGENTTRASH/trunk-law.js`). **Operator closed PR #9 unmerged** in favor of editing each repo's own AGENTS.md. Durable finding from the exploration: every context-file provider (AGENTS.md walk-up, `.omp/` dirs, CLAUDE.md) resolves at or below the repo root — a `~/Projects/AGENTS.md` for ancestor scope can never load; user-level `APPEND_SYSTEM.md` broadcasts to *all* sessions. Second finding: **serverAppConfigs never had git-flow** — its AGENTS.md mandated no branch regime at all (direct commit+push); a trunk + PR law is being added there by PR in that repo, not corrected.
## 2026-10-18 — SDLC switched to trunk-based development
`develop` retired by operator decision (single-dev repo; the branch bought nothing and cost a back-merge every release). New law in AGENTS.md § *Trunk-based SDLC*: branch off the freshest `origin/main` before every work item, PRs target `main` directly, `--no-ff` merges, tags `vX.Y.Z` straight on main. No back-merges, no release branches. The last back-merge (`527596a`) lands with this switch; the managed skill `gitflow-back-merge-plumbing` is now historical.
## 2026-10-18 — Sibling-vault overlap census; system docs realigned to live ground truth
Census of `omp-docs/` against `~/Projects/serverAppConfig/serverAppConfigs-docs/` (subagent + live-ssh verification) found four contradicting pairs; all OURS-side stale pages corrected, THEIRS side flagged only (their repo, their PR flow). Ground truth from read-only probes on both boxes 2026-10-18.
* **Hardware drift corrected** (`system/dankserver.md`, `system/dankclaw.md` rewritten, `AGENTS.md` machine table): RTX 3090 moved Dankserver→Dankclaw 2026-09; dankserver now 2× Radeon AI PRO R9700 (7700X stays — the "board swap" story is false), 246 GiB RAM, no swap; dankclaw 121 GiB RAM + 64 GiB swap. Served models per live units: frank-archon (:7770 dankserver, radiance TP=2 iq4r), frank-dragoon (:7770 dankclaw, halogen NATIVE v2, iGPU), frank-zealot (:7771 dankclaw, llama.cpp PrismML, Ternary-Bonsai-2-27B PQ2_0, 3090). Both kernels 7.0.0-38-generic; dankclaw :7770 needs no auth.
* **Gitea pages corrected** (`tools/gitea/` index + 3 subpages): `gitea-caddy` quadlet retired — fleet Caddy fronts the domain; data tree is `/home/dank/Containers/gitea/{data,postgres,env}` (2026-09-01 standard), `/opt/gitea/` is a do-not-use leftover; LAN IP, live domain, no WAN address.
* **Pi-era pages demarcated as archive** (`pi/index.md`, `core/index.md` banners; `core/index.md` said settings.md was "Current"): `frank-default-small/large` endpoints, role tables, and 3090/4070 hardware rows now read as pi-era records. `tools/llama-cpp/index.md` fleet note modernized to the one remaining llama.cpp endpoint (zealot :7771).
* **Their-side staleness flagged, NOT edited** (for operator clarification): `Agent/OMP Harness.md` still says thresholdPercent 70 — live config is **95** (`agent/config.yml:84`); `index.md:18` says Dankserver Ubuntu 24.04 vs their own specs page 26.04; `Dankclaw/Stack.md` "current mapping (2026-09-03)" predates the ACTIVE dragoon/zealot runbooks it links beside; `index.md:548` links the superseded pi-era KB at `~/.pi/agent/docs/`.
* Consistent duplicates (no action): niri/noctalia desktop pages, Caddy reference. Divergence clarified: their "composer" = OpenWebUI chat box; ours = omp composer shape — unrelated subjects.
## 2026-10-18 — Status line docs truth audit (full-source re-verification)
Exhaustive claim-by-claim re-audit of [OMP Status Line Customization](/pi/statusline.md) against the minified `dist/cli.js` bundle plus a live screenshot matrix (band × {off, percentage, embedded}, claude × off). Page carries an **Audit log** section; four first-pass claims were false and are corrected (see there): claude's rule is *not* the context meter (meter is `box`/`band` only; the "red rule" was the session-accent filler), the "Tern-only" composer-bar claim was bogus (the readout is `composer.tokenRate`, default off), `segmentOptions` are **not** gated to `preset: custom` (only the segment arrays are), and the `mode` segment's states are Plan/Prewalk/Goal/Vibe/Loop (no yolo). Page expanded with: the 7-preset defaults table, per-shape `statusAttachment`/`bottomBar` model (8 built-ins + plugin shape registry), `contextLine` per-value behavior, the 27-segment catalog with triggers/options, `segmentOptions` schema, and the full `statusLine.*`/`composer.*` knob registry. The bundle's own "(box composer only)" knob description for `contextLine` is upstream-wrong — band honors it.
ServerAppConfigs-docs overlap census: flagged separately for the operator (morning report); no doc merged/changed on either side.
## 2026-10-18 — Status line rebuilt on custom segments; frank-archon display name slimmed
Interactive tune-up of the omp status bar (grilling session, live loop: config edit → watcher repaint → niri screenshot verify). New knowledge page: [OMP Status Line Customization](/pi/statusline.md).
* **Mechanics discovered:** `leftSegments`/`rightSegments` are inert unless `preset: custom` (fleet was on `nerd` with dead arrays; `segmentOptions` *do* merge under named presets); `composer.shape` routes them — `band` merges both arrays into one row above the editor (title rides the working row), `claude` splits them into top chip + bottom strip. The context meter exists **only in `box`/`band`** — `contextLine`: `off` plain rule, `embedded` hoists the context segment into the labeled inline meter (`60% ——— × 200K`), `percentage`/`annotated` paint an unlabeled proportional rule meter (all four live-verified); every other shape's rule is a constant session-accent filler. Working row (session title + tok/s readout gated by `composer.tokenRate`, default off) is composer chrome — model/thinking can never join it. Eight composer shapes ship in the bundle; plugins can register more.
* **Mechanics discovered:** `leftSegments`/`rightSegments` are inert unless `preset: custom` (fleet was on `nerd` with dead arrays); `composer.shape` routes them — `band` merges both arrays into one row above the editor (title rides the working row), `claude` splits them into top chip + bottom strip. The `claude` red rule **is** the context meter (length = usage); `contextLine` label variants render in `box`/`band` — `band` paints the labeled inline meter (`60% ——— × 200K`). Working row (`⠿ Working… + tok/s`) is hardcoded — model/thinking can never join it (Tern-only). Eight composer shapes registered in the bundle.
* **Final bar (`band`, after a `claude` sojourn):** left = `session_name · vim · mode · hostname · path · git(no branch text) · pr`; right cluster in array order = `model · cost · time_spent` (`context_pct` hoists out of the run to paint the labeled inline meter `60% ——— × 200K` as a flexible spacer between the groups). Cut: tok/s duplicate, clock, cache trio, `context_total`, `subagents`, `session` hash, and `token_in`/`token_out` (cumulative totals live in `/session`). `path`: logical `project/worktree` label (`stripWorkPrefix: true`, kept after a live `false` trial of the full cwd); branch text dropped (worktree branches are autogenerated), dirty badges kept.
* **models.yml:** frank-archon display `name` slimmed to `"frank-archon"` (endpoint suffix dropped; `id` untouched).
* **Out of scope noted:** worktree name generation (`wt-<date>-<hash>`) is omp-internal; possible upstream feature request.
+3 -7
View File
@@ -1,12 +1,8 @@
# Pi Configuration
> **Archive note (2026-10-18).** Most pages in this directory document the retired
> **pi** harness (settings.json / models.json, `frank-default-*` endpoints, verified
> 2026-08-28). The live harness is **omp** — its config is `agent/config.yml` +
> `agent/models.yml` in this repo, the current fleet endpoints are on
> [System hosts](/system/index.md), and omp-specific knowledge lands in pages like
> [OMP Status Line Customization](/pi/statusline.md) below. Read pi pages as
> historical records, not current state.
Documentation for the pi coding agent installation on ](../system/index.md).
Everything here is configured locally on the workstation; the LLM providers are the
two llama.cpp servers (Dankserver, Dankclaw).
## Configuration Files
+55 -151
View File
@@ -1,7 +1,7 @@
---
type: reference
title: OMP Status Line Customization
description: How the omp status line actually works — presets vs custom arrays, composer-shape segment routing, the context meter (box/band only), the 27-segment catalog, and the fleet's tuned layout.
description: How the omp status line actually works — presets vs custom arrays, composer-shape segment routing, the context meter, and the fleet's tuned segment layout.
tags:
- omp
- tui
@@ -12,89 +12,36 @@ timestamp: 2026-10-18
# OMP Status Line Customization
Ground truth from the installed bundle (`@oh-my-pi/pi-coding-agent/dist/cli.js`),
verified live on blankpad 2026-10-18 and re-audited line-by-line against the
minified source the same day (see [Audit log](#audit-log)). Status knobs live
in `agent/config.yml` under `statusLine:`; the two composer knobs
(`composer.shape`, `composer.tokenRate`) under `composer:`. The file is
file-watched — edits repaint a running session without restart (verify
visually: niri screenshot, see [niri capture recipe](../system/index.md)).
`/settings` (Appearance tab) previews these live with sample data.
Ground truth from the installed bundle (`@oh-my-pi/pi-coding-agent/dist/cli.js`)
verified live on blankpad 2026-10-18. All knobs live in
`agent/config.yml` under `statusLine:` (tracked — see
[Command Center repo](../core/index.md)); the file is file-watched, so edits
repaint a running session without restart (verify visually: niri screenshot,
see [niri capture recipe](../system/index.md)).
## Preset vs custom — the trap
`statusLine.preset` ships whole configurations. **`leftSegments` /
`rightSegments` are ignored unless `preset: custom`** (`s ? user ?? preset
: preset` in the resolver). **`segmentOptions` is NOT gated** — user options
merge over the preset's own options under *every* preset.
| preset | leftSegments | rightSegments | separator |
|---|---|---|---|
| `default` | pi vim model mode collab stream path git pr context_pct cost | session_name | powerline-thin |
| `minimal` | vim path git | session_name mode context_pct | slash |
| `compact` | vim model mode git pr | session_name cost context_pct | powerline-thin |
| `full` | pi vim hostname model mode path git pr subagents | session_name cache_hit token_in token_out token_rate cache_read cost context_pct time_spent time | powerline |
| `nerd` | pi vim hostname model mode path git pr session subagents | session_name token_in token_out cache_read cache_write token_rate cost context_pct context_total time_spent time | powerline |
| `ascii` | vim model mode path git pr | session_name token_total cost context_pct | ascii |
| `custom` | your `statusLine.leftSegments` | your `statusLine.rightSegments` | powerline-thin |
The built-in default for `statusLine.leftSegments`/`rightSegments` themselves
is the `ascii`-era pair (`vim model mode path git pr` / `session_name
token_total cost context_pct`) — a config carrying those arrays with a named
preset is running the preset, not the arrays. The fleet runs `preset: custom`.
`statusLine.preset` ships whole configurations (`default`, `minimal`,
`compact`, `full`, `nerd`, `ascii`, `custom`). **`leftSegments` /
`rightSegments` / `segmentOptions` are only read when `preset: custom`** —
with any named preset they are silently ignored. The fleet config runs
`preset: custom`.
## Composer shape routes the segments
`composer.shape` decides *where* the two arrays render. Eight shapes ship in
the bundle; the plugin API can register more (`zG()` = built-ins + a live
registration map). Internally each shape carries `statusAttachment`,
`bottomBar`, `bottomBarGap`:
`composer.shape` decides *where* the two segment arrays render:
| shape | attach | bottom bar | leftSegments | rightSegments |
|---|---|---|---|---|
| `band` (fleet, default) | top-band | none | merged single row above editor, left | same row, right (`session_name` skipped — title rides the working row) |
| `box` | top-border | none | box top border | box top border |
| `claude` | top-rule-chip | left | bottom strip, left | top rule chip, right-aligned |
| `rule` | top-rule-chip | left + gap | like claude, gap above strip | like claude |
| `pi` | none | full | single bottom bar | single bottom bar |
| `borderless` | none | full | single bottom bar | single bottom bar |
| `field` / `rail` | none | full + gap (filled surface) | single bottom bar | single bottom bar |
| shape | leftSegments | rightSegments |
|---|---|---|
| `band` (fleet) | merged single row above editor | same row, right side (title skipped — it rides the working row) |
| `claude` | bottom strip, left-aligned | top rule chip, right-aligned |
| `rule` | same as claude, gap above strip | same |
| `box` | box top border | box top border |
| `borderless` / `pi` / `field` / `rail` | single bottom bar | single bottom bar |
The chip/strip layouts paint their rules as **session-accent fillers, not
meters** — the context meter exists only in `box` and `band`
(see next section). The top-rule chip renders right segments only, the bottom
strip left segments only.
The working row is composer chrome, not segment-addressable: session title +
shimmer, plus the tok/s readout when `composer.tokenRate: true` (default
false). The readout is estimated from streamed deltas, corrected by billed
output counts; the bundle also mentions a native-composer-bar placement in
filled styles.
## The context meter
`statusLine.contextLine` (enum `off` / `percentage` / `annotated` /
`embedded`, default `embedded`) tunes the rule between the segment groups.
The knob description says "box composer only" — **that is wrong**: the meter
renders in `box` **and** `band`; in every other shape the rule is a constant
session-accent filler regardless of this setting (live-verified claude with
`off` vs `embedded`: identical, and not context-proportional).
In box/band:
- `off` → plain accent rule (single color, full width).
- `embedded` → the inline labeled meter: `60% ——— × 200K`. Requires
`contextWindow > 0`, a `context_pct`/`context_total` segment present in
either array, and at least one non-context segment. The context segment(s)
are **hoisted out of the arrays** — they never render as text in this mode.
- `percentage` / `annotated` → unlabeled proportional meter painted into the
rule (live-verified in band: colored fill ∝ usage at the rule's right end);
`context_pct` stays a normal text segment.
Fill length ∝ `min(100, contextPercent)`; >100% paints the raw percent and
shortens the meter. Meter/segment color thresholds scale with window size —
warning at ≥ min(50 %, 150K tokens), purple ≥ min(70 %, 270K), error ≥
min(90 %, 500K); below that the theme's `statusLineContext` color.
The `⠿ Working…` row is hardcoded: shimmer text + `composer.tokenRate` readout
(+ session title in `band` only). Model/thinking-level can never join it
despite the settings description — that composer-bar behavior is Tern-only.
## Segment universe (27)
@@ -103,33 +50,22 @@ min(90 %, 500K); below that the theme's `statusLineContext` color.
`context_total`, `time_spent`, `time`, `session`, `hostname`, `cache_read`,
`cache_write`, `cache_hit`, `session_name`, `usage`, `collab`, `stream`, `vim`.
Zero/inactive segments render nothing — dead weight costs no width.
Conditional segments render nothing until their trigger exists: `vim` needs
`tui.vimMode`, `mode` needs plan/yolo, `pr` needs an associated PR, `git` shows
staged/unstaged/untracked badges (branch text optional via
`segmentOptions.git.showBranch`), `status` needs an extension push.
`session` = first 8 chars of the session id (resume-by-id handle).
| segment | renders | trigger / notes |
|---|---|---|
| `pi` | brand glyph + turn-elapsed | while streaming; focused-agent ghost id (warning color) when a subagent is focused |
| `status` | hook/extension statuses, dot-joined | extension pushes via `ctx.ui.setStatus()` (ordered by key); suppressed in footer when `statusLine.showHookStatus: false` |
| `model` | display `name` + thinking level | suffix hidden by `segmentOptions.model.showThinkingLevel: false`; `statusLine.compactThinkingLevel: true` (default) swaps in a compact glyph; fast-mode, advisor/tariff badges attach here |
| `mode` | `Plan` / `Prewalk` / `Goal` / `Vibe` / `Loop …` | only in those modes (paused variants add a pause glyph); there is **no yolo/auto-approval display** in this segment |
| `path` | cwd or `project/worktree` label | see [Path segment](#path-segment-and-stripworkprefix) |
| `git` | branch + dirty badges | `+N` staged, `*N` unstaged, `?N` untracked (`segmentOptions.git.showStaged/showUnstaged/showUntracked`, default true); `showBranch: false` hides branch text and keeps badges (git icon carries them); color flips on dirty |
| `pr` | `#<number>` hyperlink | only once the session has an associated PR |
| `subagents` | count | hidden at 0; when subagents are actively running the composer paints its own live badge and this segment self-suppresses |
| `token_in` / `token_out` | cumulative session input/output tokens | hidden at 0; `cache_read` / `cache_write` likewise cumulative |
| `token_total` | `input + output + cache_write + orchestration_in + orchestration_out` | hidden at 0 |
| `token_rate` | `N.N tok/s` | hidden when not streaming (the working-row readout is a separate, `composer.tokenRate`-gated thing) |
| `cost` | session cost | includes subagent-tree + advisor cost; `↑`/`↓` peak/off-peak arrow for time-priced providers |
| `context_pct` | `NN.N%/200K` (or window alone when percent is unknown) | hoisted into the meter in `embedded` box/band; auto-compact speculation icon rides along |
| `context_total` | absolute context tokens | also hoisted by the embedded meter |
| `time_spent` | active session time | hidden under 1 s; this is *active* time, not wall clock |
| `time` | wall clock | `segmentOptions.time.format: "12h"/"24h"`, `showSeconds` |
| `session` | first 8 chars of session id (`new` before resume exists) | resume-by-id handle |
| `session_name` | session title, accent | in `band` it renders on the working row instead |
| `hostname` | short hostname | accent-tinted with session color |
| `usage` | rate-limit windows | 5h / daily / 7d / monthly bars + tier badge, when the provider reports them |
| `collab` | `collab:N` / `collab guest:N` | only in collab sessions |
| `stream` | `● LIVE <viewers>` / `● REC` | only while streaming/recording |
| `vim` | mode glyph/word | only while vim keybindings are active; selected-line count appended (` 3L`); `display` icon vs text comes from the vim runtime, not config |
## The context meter
In the `band` shape (fleet) the meter is the labeled inline line between the
segment groups (`60% ———— × 200K`). In the `claude` shape the red rule left of
the right-segment chip **is** the meter: its length tracks context usage.
`statusLine.contextLine` (`off` / `percentage` / `annotated` / `embedded`)
only changes rendering in `box`/`band` — in `claude` all non-`off` values
look identical. Docs' claim that contextLine is "box composer only" is
wrong for the meter itself; the labeled inline variant is the box/band-only
part.
## Path segment and `stripWorkPrefix`
@@ -145,55 +81,23 @@ Zero/inactive segments render nothing — dead weight costs no width.
2. **All sessions:** `true` uses the pretty display path (scratch sessions
get the scratch-folder icon); `false` uses the raw absolute cwd.
`abbreviate` (default **true**: home → `~`; `false` keeps the full path —
also affects tool labels/errors per upstream docs) and `maxLength` (clip,
default 40) apply afterwards in both modes. The fleet runs `true` — logical
label, worktree glyph (verified live 2026-10-18; an earlier trial of `false`
for the full cwd was rejected by eye).
## Status knobs (registry-verified)
`statusLine.preset` · `.leftSegments` · `.rightSegments` · `.segmentOptions` ·
`.separator` (`powerline` `powerline-thin` `slash` `pipe` `block` `none`
`ascii`; default `powerline-thin`) · `.contextLine` · `.sessionAccent`
(default true; hashes the session name into the editor border *and* the
accent-tinted segments/meter color) · `.transparent` (terminal background,
no status bg fill) · `.showHookStatus` · `.compactThinkingLevel` (default
true). Plus `symbolPreset` at top level (`unicode` `nerd` `ascii` — segment
glyphs follow it).
`abbreviate` and `maxLength` (clip, default 40) apply afterwards in both
modes. The fleet runs `true` — logical label, worktree glyph (verified live
2026-10-18; an earlier trial of `false` for the full cwd was rejected by eye).
## Fleet configuration (2026-10-18)
- Shape `band`: one merged status row. Left group: `session_name`→working
row (skipped), `vim`, `mode`, `hostname`, `path`, `git` (no branch text —
worktree branches are autogenerated names), `pr`. Right group (array order
= paint order, so the last entry hugs the screen edge): `model`, `cost`,
`context_pct`, `time_spent` — `context_pct` hoists out of the run to paint
the labeled inline meter (`60% ——— × 200K`) between the groups under
`contextLine: embedded`.
- Deliberately cut: `token_rate` (working-row readout covers it), `time`
(panel clock), `cache_*` (noise), `context_total` (implied by the meter),
`subagents` (live badge supersedes it), `session`, `token_in`/`token_out`
(cumulative totals are in `/session` anyway).
- `models.yml`: frank-archon's display `name` slimmed to `"frank-archon"`
(endpoint suffix dropped); frank-dragoon/frank-zealot keep their endpoint
suffixes. `name:` is free-form display, `id:` is the wiring — renaming ids
is the cutover procedure, see [Pi Models](/pi/models.md).
## Audit log
2026-10-18 full-source re-audit corrected the first pass of this page:
- ~~claude shape's top rule is the context meter~~ — **false**. The
meter code path runs only for `box`/`band`; claude/rule/pi/borderless/
field/rail rules are constant session-accent fillers. (Earlier reading
mistook the accent rule for a meter.)
- ~~working-row composer-bar variant is "Tern-only"~~ — **false**; the
tok/s readout is the `composer.tokenRate` option (default false), title
placement is composer chrome.
- ~~`segmentOptions` gated to `preset: custom`~~ — **false**; options merge
under every preset, only the segment *arrays* are gated.
- ~~`mode` covers yolo~~ — **false**; states are Plan/Prewalk/Goal/Vibe/Loop.
- `contextLine` "(box composer only)" — the *bundle description* is wrong;
band honors it too (verified live: `off` plain rule, `percentage` rule
meter, `embedded` inline meter, screenshots + code).
- Shape `band`: one merged status row. Left group: `session_name`, `vim`,
`mode`, `hostname`, `path`, `git` (no branch text — worktree branches are
autogenerated names), `pr`. Right group (array order = paint order, so the
last entry hugs the screen edge): `model`, `cost`, `context_pct`,
`time_spent` — `context_pct` hoists out of the run to paint the labeled
inline meter (`60% ——— × 200K`) as a flexible spacer between the groups.
`session_name` renders on the working row, not the status row.
- Deliberately cut: `token_rate` (lives on the working row), `time` (panel
clock), `cache_*` (noise), `context_total` (implied by the meter),
`subagents`, `session`, `token_in`/`token_out` (cumulative totals are
in `/session` anyway).
- Model display names slimmed in `models.yml` (`frank-archon`, no endpoint
suffix); `name:` is free-form display, `id:` is the wiring — renaming ids is
the cutover procedure, see [Pi Models](/pi/models.md).
+47 -43
View File
@@ -1,79 +1,83 @@
---
type: reference
title: Dankclaw
description: Inference and services box at 192.168.0.143 — frank-dragoon (halogen-flash-server, Strix Halo iGPU, :7770) and frank-zealot (llama.cpp on the RTX 3090, :7771), plus Gitea/Caddy/OpenWebUI services.
description: Secondary inference server at 192.168.0.143. Runs llama.cpp (frank-default-large).
tags:
- network
- llamacpp
- inference
- server
- comfyui
- unverified
generated:
by: chief-designer/agent
at: 2026-08-26T00:00:00Z
verified: 2026-10-18
verified: 2026-08-28
---
# Dankclaw
Strix Halo mini-PC carrying the fleet's secondary models and most of the
service stack (Gitea, Caddy, OpenWebUI, SearXNG). Two GPU-class devices: the
Radeon 8060S iGPU with 119 GiB unified memory, and the RTX 3090 moved over
from Dankserver in September 2026.
Secondary llama.cpp inference server for the Frank Program. Serves larger models used by planner, worker, reviewer, oracle, and context-builder subagents.
## Connection Details
| Property | Value |
|----------|-------|
| **Hostname** | dankclaw |
| **IP Address** | 192.168.0.143 (LAN) |
| **Auth** | none required on :7770 (verified 2026-10-18) |
| **IP Address** | 192.168.0.143 |
| **Port** | 7770 |
| **Base URL** | `http://192.168.0.143:7770/v1` |
| **API** | OpenAI-compatible completions |
| **Authentication** | API key configured |
## Inference Services
## Models
| Model ID | Unit | Endpoint | Engine / weights |
|----------|------|----------|------------------|
| `frank-dragoon` | `frank-dragoon.service` (root) | `:7770` | halogen-flash-server container — Quat3rnion NATIVE v2 abliterated Qwen3.8-Flash-Next, MTP spec decode, 2 slots over ONE 200,704-position pool, vision ON, **Strix Halo iGPU** (unified memory) |
| `frank-zealot` | `frank-zealot.service` (root) | `:7771` | llama.cpp (PrismML fork, build 10754) — Ternary-Bonsai-2-27B PQ2_0 GGUF (qwen35 hybrid), 2×200,704 slots, q8_0 K+V, mmproj vision, **RTX 3090** |
| Model ID | Context Window | Reasoning | Input Types |
|----------|---------------|-----------|-------------|
| `frank-default-large` | 262,144 tokens | Yes | Text, *Image* (unverified) |
Harness-side context windows (`agent/models.yml`): dragoon 155,648,
zealot 200,704 per slot. The models.yml display labels "(dankclaw-gpu)" /
"(dankclaw-3090)" predate naming cleanup; the hardware column above is
current. Subagent roles `scout`, `sonic`, `designer`, `librarian`,
`security-reviewer` route to frank-zealot; `reviewer`/`task` run on
frank-archon (Dankserver).
## Services
```bash
curl http://192.168.0.143:7770/v1/models # dragoon
curl http://192.168.0.143:7771/v1/models # zealot
```
## Hardware (verified live 2026-10-18)
### llama.cpp
| Property | Value |
|----------|-------|
| **CPU/APU** | AMD Ryzen AI MAX+ 395 (Strix Halo, Radeon 8060S, gfx1151) |
| **dGPU** | NVIDIA GeForce RTX 3090 (moved from Dankserver 2026-09) |
| **RAM** | 121 GiB (mostly usable as GPU unified memory) |
| **Swap** | 64 GiB |
| **OS** | Ubuntu 26.04 LTS, kernel 7.0.0-38-generic |
| **Port** | 7770 |
| **Models** | `frank-default-large` |
The pre-rename story (`frank-default-large` on ROCmFPX llama.cpp/CIRU,
262,144-token context) was superseded by the 2026-10-08/09 model-id rename
and the dragoon/zealot engine swaps; the 119→121 GiB RAM figure follows the
live `free` reading.
## Hardware
## Related Knowledge Bases (sibling project)
| Property | Value |
|----------|-------|
| **CPU** | AMD Ryzen AI MAX+ 395 (16C/16T, Strix Halo) |
| **GPU** | Radeon 8060S integrated (gfx1151, amdgpu) |
| **RAM** | 119 GiB |
| **Storage** | Kingston SNV3S1000G NVMe (931.5 GB), ~676 GB free |
| **OS** | Ubuntu 26.04 LTS, kernel 7.0.0-30-generic |
| **ROCm** | 7.2.4 (driver: 7.0.0-30-generic) |
| **Python** | 3.14.4 (system) |
- **serverAppConfigs** — deployment repo + vault, on this workstation at
`~/Projects/serverAppConfig/` (docs vault: `~/Projects/serverAppConfig/serverAppConfigs-docs/`).
Live runbooks: `LLM/frank-dragoon-flash-server-v2-native.md` and
`LLM/frank-zealot-llama-prism-bonsai2-pq20.md` — deploy-side source of
truth for engines, flags, and restart procedures. Service stack docs under
`Dankclaw/`, `Infrastructure/`.
## Usage
Dankclaw handles complex tasks delegated by subagent overrides. The `frank-default-large` model provides extended context. *Multimodal input support is unverified.*
```bash
# Health check
curl http://192.168.0.143:7770/health
# Test with large model
curl http://192.168.0.143:7770/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <key>" \
-d '{"model":"frank-default-large","messages":[{"role":"user","content":"Hello"}],"max_tokens":32}'
```
## Related Knowledge Bases (sibling project on the workstation)
- **serverAppConfigs** — `/home/dank/Projects/serverAppConfigs/` — Podman deployment config for this host (AI, search, development, observability stack, incl. the Hermes compose service) **plus the LLM inference fleet** (frank-default-large, CIRU ROCmFPX llama.cpp, :7770). The former `vllmScripts` repo merged into it on 2026-08-22 (history preserved). Start at `/home/dank/Projects/serverAppConfigs/docs/index.md` (see `dankclaw/compose.yaml` + `docs/Dankclaw/`; LLM fleet at `docs/LLM/index.md`, deploy runbook at `docs/LLM/deployment.md`).
## See Also
- [[dankserver|dankserver]] — the main-model box (frank-archon)
- [/tools/gitea/index.md](/tools/gitea/index.md) — Gitea stack on this host
- [[models|models]] — Provider definitions
- [[dankserver|dankserver]] — Primary server
- [[network|network]] — Network topology
+22 -36
View File
@@ -1,24 +1,22 @@
---
type: reference
title: Dankserver
description: Radiance inference server at 192.168.0.235:7770, serving frank-archon (Qwen3.8-Flash-Next iq4r, 2x R9700 TP=2, 200,000-token context).
description: Primary llama.cpp inference server at 192.168.0.235:7770, serving frank-default-small with 163,840-token context window.
tags:
- network
- llamacpp
- inference
- server
- unverified
generated:
by: chief-designer/agent
verified: 2026-10-18
verified: 2026-08-28
status: stable
---
# Dankserver
Primary inference server for the Frank Program. Serves `frank-archon`, the
main agent model, from a pair of Radeon AI PRO R9700s (tensor-parallel 2).
The RTX 3090 that used to live here was removed 2026-09-15 and now runs on
Dankclaw.
Primary llama.cpp inference server for the Frank Program. Serves `frank-default-small` — a fast, capable model with image support.
## Connection Details
@@ -30,24 +28,19 @@ Dankclaw.
| **Base URL** | `http://192.168.0.235:7770/v1` |
| **API** | OpenAI-compatible completions |
| **Authentication** | None |
| **Systemd unit** | `frank-archon.service` (root) |
## Model
| Property | Value |
|----------|-------|
| **Model ID** | `frank-archon` (display name `frank-archon`) |
| **Weights** | Qwen3.8-Flash-Next, radiance iq4r (publisher build) |
| **Engine** | radiance, tensor-parallel 2 across both R9700s |
| **Context Window** | 200,000 tokens (harness `models.yml`; served pool may differ — see runbook) |
`frank-medium` (former dual-GPU mid tier) is masked and retired.
| **Model ID** | `frank-default-small` |
| **Context Window** | 163,840 tokens |
| **Reasoning** | Supported |
| **Input Types** | Text, *Image* (unverified) |
## Usage
Dankserver carries the main-session model. Subagent role overrides in
`agent/models.yml` route here for `task` and `reviewer`; scout/sonic/designer
route to Dankclaw.
Dankserver serves the small subagent model `frank-default-small`. Small subagent roles route here unless a role override picks a different model.
```bash
# Health check
@@ -56,34 +49,27 @@ curl http://192.168.0.235:7770/health
# Quick test
curl http://192.168.0.235:7770/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"frank-archon","messages":[{"role":"user","content":"Hello"}],"max_tokens":32}'
-d '{"model":"frank-default-small","messages":[{"role":"user","content":"Hello"}],"max_tokens":32}'
```
## Hardware (verified live 2026-10-18)
## Hardware
| Property | Value |
|----------|-------|
| **CPU** | AMD Ryzen 7 7700X (8C/16T, Raphael iGPU on board) |
| **GPU** | 2× AMD Radeon AI PRO R9700 (Navi 48, 32 GiB each) |
| **RAM** | 246 GiB |
| **Swap** | effectively none (~0.1 GiB) — the 64 GiB swapfile is on Dankclaw, not here |
| **Storage** | 7× 18.2 TB HDD + 1.8 TB NVMe (layout owned by the deploy repo) |
| **OS** | Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic |
| **CPU** | AMD Ryzen 7 7700X (8C/16T, Raphael) |
| **GPU** | NVIDIA GeForce RTX 3090 (24 GiB VRAM, EVGA) |
| **RAM** | 60 GiB |
| **Swap** | 64 GiB (/swapfile) |
| **Storage** | Kingston SNV3S1000G NVMe (931.5 GB) + md0 RAID (6×18.2T Toshiba, /mnt/entropy, 91T) |
| **OS** | Ubuntu 26.04 LTS, kernel 7.0.0-30-generic |
| **NVIDIA Driver** | 595.84 |
The old page (verified 2026-08-28) listed an RTX 3090, 60 GiB RAM, and a
64 GiB swapfile here; all three were superseded by the 2026-09 hardware swap.
## Related Knowledge Bases (sibling project on the workstation)
## Related Knowledge Bases (sibling project)
- **serverAppConfigs** — deployment repo + vault, on this workstation at
`~/Projects/serverAppConfig/` (docs vault: `~/Projects/serverAppConfig/serverAppConfigs-docs/`).
Podman/quadlet deploy config for both servers plus the LLM inference fleet.
The live frank-archon runbook (engine flags, KV pool sizing, restart
procedures) is `LLM/frank-archon-radiance-qwen38-iq4r.md` in that vault —
it, not this page, is the deploy-side source of truth.
- **serverAppConfigs** — `/home/dank/Projects/serverAppConfigs/` — Podman deployment config for this host (media and library stack: RomM, Copyparty, Calibre-Web) **plus the LLM inference fleet** (frank-default-small, llama.cpp, :7770). The former `vllmScripts` repo merged into it on 2026-08-22 (history preserved). Start at `/home/dank/Projects/serverAppConfigs/docs/index.md` (see `dankserver/compose.yaml` + `docs/Dankserver/`; LLM fleet at `docs/LLM/index.md`, deploy runbook at `docs/LLM/deployment.md`).
## See Also
- [[dankclaw|dankclaw]] — the other inference box (dragoon + zealot)
- [[models|models]] — Provider definitions
- [[dankclaw|dankclaw]] — Secondary server
- [[network|network]] — Network topology
- [/pi/statusline.md](/pi/statusline.md) — where these models surface in the TUI
+5 -5
View File
@@ -11,8 +11,8 @@ Dankclaw are the inference servers it talks to.
## Network Systems
- [Dankserver](/system/dankserver.md) — Main-model inference server at 192.168.0.235:7770, serving `frank-archon` (radiance Qwen3.8-Flash-Next, 200K ctx). AMD Ryzen 7 7700X, 2× Radeon AI PRO R9700, Ubuntu 26.04.
- [Dankclaw](/system/dankclaw.md) — Secondary inference + services box at 192.168.0.143: `frank-dragoon` (:7770, halogen-flash-server on the Strix Halo iGPU) and `frank-zealot` (:7771, llama.cpp on the RTX 3090). AMD Ryzen AI MAX+ 395, Ubuntu 26.04.
- [Dankserver](/system/dankserver.md) — Primary llama.cpp inference server at 192.168.0.235:7770, serving `frank-default-small` (163,840-token context). AMD Ryzen 7 7700X, RTX 3090, Ubuntu 26.04.
- [Dankclaw](/system/dankclaw.md) — Secondary inference server at 192.168.0.143:7770, serving `frank-default-large` (262,144-token context). AMD Ryzen AI MAX+ 395 (Strix Halo), Ubuntu 26.04, ROCm.
## Infrastructure Diagram
@@ -26,8 +26,8 @@ graph TB
end
subgraph Network[192.168.0.0/24]
E[dankserver<br/>192.168.0.235:7770<br/>frank-archon]
F[dankclaw<br/>192.168.0.143:7770 dragoon<br/>:7771 zealot]
E[dankserver<br/>192.168.0.235:7770<br/>frank-default-small]
F[dankclaw<br/>192.168.0.143:7770<br/>frank-default-large]
end
D --> E
@@ -42,7 +42,7 @@ graph TB
The fleet has one sibling OKF knowledge base outside this bundle. Read it for
deployment and inference details. This bundle links to it from the server pages.
* **serverAppConfigs** — deploy repo + Obsidian vault, on this workstation at `~/Projects/serverAppConfig/` with docs in `~/Projects/serverAppConfig/serverAppConfigs-docs/` (root `index.md` at the vault top — the old `docs/` prefix is gone). Podman deployment configuration for both servers: compose/quadlet files, Caddy reverse proxy, deploy scripts, bats tests, and the vault service docs (Dankclaw, Dankserver, Architecture, Infrastructure) — **plus the LLM inference fleet** (merged from the former `vllmScripts` repo on 2026-08-22, history preserved): radiance frank-archon on Dankserver (:7770), halogen frank-dragoon (:7770) and llama.cpp frank-zealot (:7771) on Dankclaw. The vault's `LLM/` runbooks are the deploy-side source of truth; this bundle documents the agent/harness side.
* **serverAppConfigs** — `/home/dank/Projects/serverAppConfigs/` (index: `/home/dank/Projects/serverAppConfigs/docs/index.md`). Podman deployment configuration for both servers: compose files, Caddy reverse proxy, deploy scripts, bats tests, and the Obsidian-vault service docs (Dankclaw, Dankserver, Architecture, Infrastructure) — **plus the LLM inference fleet** (merged from the former `vllmScripts` repo on 2026-08-22, history preserved): llama.cpp on Dankserver (:7770, `frank-default-small`) and CIRU ROCmFPX llama.cpp on Dankclaw (:7770, `frank-default-large`). LLM fleet docs: `docs/LLM/index.md`; deploy runbook: `docs/LLM/deployment.md`.
## Related
+5 -4
View File
@@ -5,12 +5,13 @@ description: Gitea container architecture, network topology, and Caddy reverse p
tags:
- gitea
- architecture
verified: 2026-10-18
- unverified
verified: 2026-08-28
---
# Gitea Architecture
Two quadlet-managed containers (Gitea, PostgreSQL) on a shared private Podman network (rootless, user `dank`). Gitea connects to PostgreSQL via network DNS. The fleet Caddy (separate stack, see [/caddy/index.md](/caddy/index.md)) proxies HTTP/S to Gitea — the old dedicated `gitea-caddy` container is retired.
Three quadlet-managed containers on a shared private Podman network (rootless, user `dank`). Gitea connects to PostgreSQL via network DNS. Caddy proxies HTTP/S to Gitea.
## Network Topology
@@ -62,10 +63,10 @@ Key environment variables:
- `DATABASE_HOST=gitea-postgres` (network DNS)
- `DATABASE_NAME=gitea`
- `DATABASE_USER=gitea`
- `DATABASE_PASSWD` from `/home/dank/Containers/gitea/env` (mode 0600)
- `DATABASE_PASSWD` from `/opt/gitea/.env` (mode 0600)
- `USER_UID=1000`, `USER_GID=1000`
Gitea writes `/data/gitea/conf/app.ini` on first start (host: `/home/dank/Containers/gitea/data/gitea/conf/app.ini`). The `[database] HOST` and `PASSWD` lines in app.ini override the env vars. When you rename the database container, edit the `HOST` line in app.ini as well.
Gitea writes `/data/gitea/conf/app.ini` on first start (host: `/opt/gitea/data/gitea-gitea/gitea/conf/app.ini`). The `[database] HOST` and `PASSWD` lines in app.ini override the env vars. When you rename the database container, edit the `HOST` line in app.ini as well.
## Ports
+10 -9
View File
@@ -1,23 +1,24 @@
---
type: reference
title: Gitea Data Persistence
description: Gitea data persistence, volume mounts, ownership, and backup strategy on dankclaw (Containers/gitea layout).
description: Gitea data persistence, volume mounts, ownership, and backup strategy on dankclaw.
tags:
- gitea
- data
verified: 2026-10-18
- unverified
verified: 2026-08-28
---
# Gitea Data Persistence
All data lives on host bind mounts under `/home/dank/Containers/gitea/` (fleet storage standard since 2026-09-01; quadlet units re-pointed from the old `/opt/gitea/data/` tree, which lingers on disk as a leftover — never write to it). Containers are ephemeral. Quadlet stops remove the container (`podman run --rm --replace`). The next start recreates it. Data survives.
All data lives on host bind mounts under `/opt/gitea/data/`. Containers are ephemeral. Quadlet stops remove the container (`podman run --rm --replace`). The next start recreates it. Data survives.
## Volume Layout
| Host Path | Container Mount | Contents |
|---|---|---|
| `/home/dank/Containers/gitea/data/` | `/data` (gitea-server) | Git repositories, avatars, attachments, LFS objects, `app.ini` |
| `/home/dank/Containers/gitea/postgres/` | `/var/lib/postgresql/data` (gitea-postgres) | PostgreSQL WAL, tables, indexes |
| `/opt/gitea/data/gitea-gitea/` | `/data` | Git repositories, avatars, attachments, LFS objects, `app.ini` |
| `/opt/gitea/data/gitea-postgres/` | `/var/lib/postgresql/data` | PostgreSQL WAL, tables, indexes |
## Ownership
@@ -36,7 +37,7 @@ podman exec --user 1000 gitea-server sed -i 's/old/new/' /data/gitea/conf/app.in
Tar the entire data directory. This captures Gitea repos and PostgreSQL data in one archive.
```
tar czf gitea-backup-$(date +%F).tar.gz -C /home/dank/Containers/gitea data/ postgres/
tar czf gitea-backup-$(date +%F).tar.gz -C /opt/gitea data/
```
### PostgreSQL-only backup
@@ -47,17 +48,17 @@ Use `pg_dump` for a portable SQL dump. Useful for restoring to a different Postg
podman exec -e PGPASSWORD="$GITEA_DB_PASSWORD" gitea-postgres pg_dump -U gitea gitea > gitea-db-$(date +%F).sql
```
Set `PGPASSWORD` from `/home/dank/Containers/gitea/env` (mode 0600, `GITEA_DB_PASSWORD`).
Set `PGPASSWORD` from `/opt/gitea/.env` (mode 0600).
### Restore procedure
1. Stop the stack: `systemctl --user stop gitea-server gitea-postgres`
2. Restore data: `tar xzf backup.tar.gz -C /home/dank/Containers/gitea/`
2. Restore data: `tar xzf backup.tar.gz -C /opt/gitea/`
3. Start the stack: `systemctl --user start gitea-postgres gitea-server`
## Data Growth
- Git repositories grow with each commit and push. Monitor with `du -sh /home/dank/Containers/gitea/data/git/repositories/`.
- Git repositories grow with each commit and push. Monitor with `du -sh /opt/gitea/data/gitea-gitea/git/repositories/`.
- PostgreSQL WAL files accumulate. VACUUM via `podman exec gitea-postgres psql -U gitea -c "VACUUM;"`.
- Gitea's log files grow with usage.
+16 -16
View File
@@ -1,11 +1,11 @@
# Gitea on dankclaw
Private Git hosting on dankclaw. Two quadlet-managed containers in the rootless podman session of user `dank`: Gitea and PostgreSQL, sharing a dedicated network unit. The former `gitea-caddy` container is **retired** — the canonical fleet Caddy (`caddy.service`, see [/caddy/index.md](/caddy/index.md)) fronts `gitea.franksdank.cloud`; do not recreate the retired unit.
Private Git hosting on dankclaw. Three quadlet-managed containers in the rootless podman session of user `dank`: Gitea, PostgreSQL, Caddy.
**Host:** dankclaw (192.168.0.143 LAN)
**Config:** `~/.config/containers/systemd/gitea-{postgres,server}.container` + `gitea.network`
**Local access:** `http://dankclaw:3000` (verified 2026-10-18)
**Domain:** `https://gitea.franksdank.cloud` (live; served by fleet Caddy, DNS-01 TLS)
**Host:** dankclaw (71.227.227.172)
**Config:** `~/.config/containers/systemd/gitea-{postgres,server,caddy}.container` + `gitea.network`
**Local access:** `http://dankclaw:3000`
**Domain:** `https://gitea.franksdank.cloud` (DNS pending)
## Architecture
@@ -13,7 +13,7 @@ Private Git hosting on dankclaw. Two quadlet-managed containers in the rootless
|---|---|---|---|
| `gitea-server` | `gitea-server.service` | 3000 (HTTP), 2222 (SSH) | Git web UI, API, SSH daemon |
| `gitea-postgres` | `gitea-postgres.service` | 5432 (internal) | Database |
| (network) | `gitea-network.service` | — | quadlet `gitea.network` bring-up |
| `gitea-caddy` | `gitea-caddy.service` | 80, 443 | Reverse proxy, auto-TLS |
The containers share the private network `systemd-gitea` (quadlet `gitea.network`, DNS enabled). The automatic `podman` default network has DNS disabled; do not run the stack on it.
@@ -23,21 +23,21 @@ All commands run as `dank` on dankclaw.
| Action | Command |
|---|---|
| Start all | `systemctl --user start gitea-postgres gitea-server` |
| Stop all | `systemctl --user stop gitea-server gitea-postgres` |
| Start all | `systemctl --user start gitea-postgres gitea-server gitea-caddy` |
| Stop all | `systemctl --user stop gitea-caddy gitea-server gitea-postgres` |
| Restart Gitea only | `systemctl --user restart gitea-server` |
| Follow logs | `podman logs -f gitea-server` or `journalctl --user -u gitea-server -f` |
| Check status | `systemctl --user status gitea-postgres gitea-server` |
| Check status | `systemctl --user status gitea-postgres gitea-server gitea-caddy` |
## Data Persistence
All data lives on host bind mounts under `/home/dank/Containers/gitea/` (fleet storage standard since 2026-09-01; verified live 2026-10-18). Containers are ephemeral. Stopping a quadlet unit removes its container; the next start recreates it. Volumes survive. The old `/opt/gitea/` tree remains on disk as a leftover — do not use it.
All data lives on host bind mounts under `/opt/gitea/data/`. Containers are ephemeral. Stopping a quadlet unit removes its container; the next start recreates it. Volumes survive.
| Path | Contents |
|---|---|
| `/home/dank/Containers/gitea/data/` | Git repositories, app.ini, attachments |
| `/home/dank/Containers/gitea/postgres/` | PostgreSQL data files |
| `/home/dank/Containers/gitea/env` | EnvironmentFile (mode 0600; `GITEA_DB_PASSWORD`) |
| Volume Path | Container Mount | Contents |
|---|---|---|
| `/opt/gitea/data/gitea-gitea/` | `/data` | Git repositories, app.ini, attachments |
| `/opt/gitea/data/gitea-postgres/` | `/var/lib/postgresql/data` | PostgreSQL data files |
| `/opt/gitea/data/caddy/data/` | `/root/.local/share/caddy` | Caddy configuration, TLS certs |
See [[data-persistence|data-persistence]] for backup and restore.
@@ -49,7 +49,7 @@ See [[management|management]] for boot persistence details and troubleshooting.
## Repo Copies
The quadlet files and `.env` templates are tracked in the `serverAppConfigs` deploy repo; the sibling vault page `Infrastructure/Gitea.md` (in `~/Projects/serverAppConfig/serverAppConfigs-docs/`) is the deploy-side source of truth. Secrets live only on the host under `Containers/gitea/` (mode 0600), never in either docs tree.
The quadlet files, Caddyfile, and `.env.example` are tracked in the `serverAppConfigs` repo under `dankclaw/gitea/`. The live password lives only in `/opt/gitea/.env` on the host (mode 0600).
## See Also
+5 -4
View File
@@ -6,7 +6,8 @@ tags:
- gitea
- management
- quadlet
verified: 2026-10-18
- unverified
verified: 2026-08-28
---
# Gitea Management
@@ -44,8 +45,8 @@ After editing a quadlet file: run `systemctl --user daemon-reload`, then restart
| File | Path |
|---|---|
| Quadlet units | `~/.config/containers/systemd/gitea-*.container`, `gitea.network` |
| Secrets | `/home/dank/Containers/gitea/env` (mode 0600, `GITEA_DB_PASSWORD`) — quadlet `EnvironmentFile` |
| Gitea app config | `/home/dank/Containers/gitea/data/gitea/conf/app.ini` (container-owned, UID 100999) |
| Secrets | `/opt/gitea/.env` (mode 0600, `GITEA_DB_PASSWORD`) |
| Gitea app config | `/opt/gitea/data/gitea-gitea/gitea/conf/app.ini` (container-owned, UID 100999) |
Repo copies: `serverAppConfigs/dankclaw/gitea/` (quadlet files, `.env.example`). Copy edits to the target, then `daemon-reload` + restart.
@@ -61,7 +62,7 @@ Gitea handles database migrations automatically on startup. PostgreSQL version b
### Gitea cannot reach the database
Check the `[database] HOST` line in `/home/dank/Containers/gitea/data/gitea/conf/app.ini`. It must be `gitea-postgres:5432`. app.ini overrides the `DATABASE_HOST` env var.
Check the `[database] HOST` line in `/opt/gitea/data/gitea-gitea/gitea/conf/app.ini`. It must be `gitea-postgres:5432`. app.ini overrides the `DATABASE_HOST` env var.
Then check name resolution from the container:
+1 -1
View File
@@ -50,7 +50,7 @@ llama-server -hf ggml-org/gemma-3-1b-it-GGUF
**Defaults**: Listens on `127.0.0.1:8080`. Single slot (one concurrent request).
> **System note:** On this network the fleet inference hosts do not use the default port. As of 2026-10 the only llama.cpp endpoint is `frank-zealot` on dankclaw **:7771** (PrismML fork build); `frank-dragoon` (dankclaw :7770, halogen-flash-server) and `frank-archon` (dankserver :7770, radiance) are different engines — see [System hosts](/system/index.md). The pi-era `frank-default-small`/`frank-default-large` llama.cpp pair (each :7770) is retired; [Pi Models Configuration](../../pi/models.md) is a pi-era archive.
> **System note:** On this network the Pi inference hosts do not use the default port. Pi serves `frank-default-small` (dankserver) and `frank-default-large` (dankclaw), each on port `7770`. The local Ornith host runs on port `8080`. See [Pi Models Configuration](../../pi/models.md).
---