Wiki Log

Note: log entries in this file may reference the retired root context tree (AGENTS.ctx/), which no longer exists on disk. Those occurrences are historical provenance only; the current governance mechanism is the standalone skill library under SKILLS/. Entries are kept verbatim and this log is append-only.

[2026-04-22] bootstrap | repository scaffold

Initialized the first wiki.tazlab.net project scaffold.

Created:

• repository-level AGENTS.md schema
• README.md
• docs/llm-wiki-pattern.md
• docs/tazlab-integration.md
• wiki/index.md
• wiki/overview.md
• raw source directories and wiki content directories

Why it matters:

This establishes the durable structure that future agents can use to ingest sources, maintain knowledge pages, and later integrate the wiki cleanly into the wider TazLab context system.

[2026-04-22] restructure | tazlab-wiki context and seed knowledge pages

Created the dedicated AGENTS.ctx/tazlab-wiki/ context and seeded the first durable TazLab knowledge pages in the wiki repository.

Created or updated:

• AGENTS.ctx/tazlab-wiki/CONTEXT.md
• AGENTS.ctx/CONTEXT.md
• wiki/overview.md
• wiki/index.md
• wiki/concepts/tazlab-knowledge-layers.md
• wiki/topics/tazlab-system-map.md
• wiki/topics/tazlab-repository-map.md

Why it matters:

This gives future agents a named context that points to the wiki as an organized knowledge surface, while also providing the first durable pages that explain the overall TazLab structure and where different kinds of information belong.

[2026-04-22] restructure | repository hubs and cross-cutting architecture pages

Expanded the wiki from seed pages into a first-pass navigable knowledge base with repository hub pages and cross-cutting architecture topics.

Created or updated:

• wiki/entities/agents-ctx.md
• wiki/entities/tazpod.md
• wiki/entities/ephemeral-castle.md
• wiki/entities/tazlab-k8s.md
• wiki/entities/mnemosyne-mcp-server.md
• wiki/entities/blog-src.md
• wiki/entities/wiki-tazlab-net.md
• wiki/topics/ephemeral-castle-hetzner-vault-runtime.md
• wiki/topics/ephemeral-castle-tailscale-foundation.md
• wiki/topics/tazlab-secret-and-identity-flow.md
• wiki/topics/tazlab-cluster-delivery-flow.md
• wiki/index.md
• wiki/overview.md
• wiki/topics/tazlab-system-map.md
• wiki/topics/tazlab-repository-map.md

Why it matters:

The wiki now describes the main TazLab repositories as first-class hubs, documents the two major ephemeral-castle subdomains called out by the operator, and introduces reusable architecture pages that connect operator environment, infrastructure bootstrap, GitOps, memory, and secret flow into one navigable structure.

[2026-04-22] ingest | blog narratives and CRISP program structure

Added first source-summary coverage from the blog layer and connected it to the wiki’s architecture pages, while also introducing a CRISP program-map page to explain the design tree behind current TazLab work.

Created or updated:

• wiki/sources/blog-zero-credentials-on-disk.md
• wiki/sources/blog-tailscale-secure-backbone.md
• wiki/sources/blog-lushycorp-vault-security-architecture.md
• wiki/sources/blog-terraforming-the-cloud-vault-hetzner.md
• wiki/sources/blog-recursive-memory-compact-context.md
• wiki/topics/tazlab-crisp-program-map.md
• wiki/entities/blog-src.md
• wiki/entities/agents-ctx.md
• wiki/entities/tazpod.md
• wiki/entities/ephemeral-castle.md
• wiki/index.md

Why it matters:

The wiki now contains not only structural pages about the ecosystem, but also provenance-rich summaries of key published articles and an explicit map of the CRISP initiative tree, which makes the documentation layer more useful for both historical understanding and future agent onboarding.

[2026-04-22] restructure | flux dag and cluster layer detail

Added a code-aligned Flux DAG page for the active tazlab-k8s cluster and wired the existing cluster/secret/system pages to it so future agents can see the actual dependency order and installed workloads in one place.

Created or updated:

• wiki/topics/tazlab-flux-dag.md
• wiki/topics/tazlab-cluster-delivery-flow.md
• wiki/topics/tazlab-system-map.md
• wiki/topics/tazlab-secret-and-identity-flow.md
• wiki/entities/tazlab-k8s.md
• wiki/index.md
• wiki/overview.md

Why it matters:

The wiki now explains the cluster as an executable Flux graph, not just as a conceptual architecture. That makes it much easier to answer operational questions about which layer depends on which, what gets installed where, and where the secret, auth, database, and application surfaces actually appear.

[2026-04-22] restructure | tazlab-k8s granularity and technology trunk split

Expanded the TazLab operational trunk into dedicated tazlab-k8s layer pages and created a separate technology/reference trunk for the software stack used to run TazLab.

Created or updated:

• wiki/topics/tazlab-k8s-layers.md
• wiki/topics/tazlab-k8s-operators.md
• wiki/topics/tazlab-k8s-configs.md
• wiki/topics/tazlab-k8s-instances.md
• wiki/topics/tazlab-k8s-auth.md
• wiki/topics/tazlab-k8s-apps.md
• wiki/topics/tazlab-infrastructure-tech-stack.md
• wiki/topics/tazlab-flux-dag-troubleshooting.md
• wiki/entities/proxmox.md
• wiki/entities/talos-linux.md
• wiki/entities/tailscale.md
• wiki/entities/metallb.md
• wiki/entities/longhorn.md
• wiki/entities/terraform.md
• wiki/entities/kubernetes.md
• wiki/entities/sops.md
• wiki/entities/hashicorp-vault.md
• wiki/entities/operator-terminal-tooling.md
• wiki/sources/research-proxmox-and-talos-iac.md
• wiki/sources/research-tailscale-and-networking.md
• wiki/sources/research-talos-storage-and-persistence.md
• wiki/sources/research-kubernetes-core-models.md
• wiki/sources/research-kubernetes-secrets-and-sops.md
• wiki/sources/research-terminal-tooling.md

Why it matters:

The wiki now reflects the way the operator actually thinks about the system: one trunk for TazLab itself and a second trunk for the supporting technologies and external research that explain how the system is built and debugged.

[2026-04-22] lint | broken research links in network entities

Fixed entity references in wiki/entities/metallb.md and wiki/entities/talos-linux.md so they point at the existing wiki/sources/research-tailscale-and-networking.md summary instead of a non-existent page.

Why it matters:

This removes dead links from the technology trunk and keeps the source graph consistent for future navigation.

[2026-04-22] restructure | secret model corrected to Infisical

Updated the wiki’s secret-management pages so the current TazLab state is described as Infisical-backed GitOps delivery, with SOPS demoted to research-only status and the LushyCorp/Vault path called out as the transition track.

Created or updated:

• wiki/entities/infisical.md
• wiki/entities/sops.md
• wiki/entities/hashicorp-vault.md
• wiki/entities/tazlab-k8s.md
• wiki/topics/tazlab-secret-and-identity-flow.md
• wiki/topics/tazlab-infrastructure-tech-stack.md
• wiki/sources/research-kubernetes-secrets-and-sops.md
• wiki/index.md

Why it matters:

This prevents the wiki from teaching an outdated secret flow and keeps the current operational model aligned with the live cluster and infrastructure context.

[2026-04-22] restructure | deep Ephemeral Castle documentation sweep

Added a deeper code-backed documentation set for ephemeral-castle, including a repository map, bootstrap pipeline, Proxmox/Talos foundation page, a Tailscale foundation expansion, and an analysis note for current topology drift.

Created or updated:

• wiki/entities/ephemeral-castle.md
• wiki/topics/ephemeral-castle-repository-map.md
• wiki/topics/ephemeral-castle-cluster-bootstrap.md
• wiki/topics/ephemeral-castle-proxmox-talos-foundation.md
• wiki/topics/ephemeral-castle-tailscale-foundation.md
• wiki/topics/tazlab-cluster-delivery-flow.md
• wiki/topics/tazlab-system-map.md
• wiki/analyses/ephemeral-castle-topology-drift.md
• wiki/index.md

Why it matters:

This turns ephemeral-castle from a shallow hub into a navigable, code-aligned documentation surface that explains the actual bootstrap pipeline, module boundaries, and the current live topology without hiding doc drift.

[2026-04-23] restructure | wiki homepage draft

Added wiki/homepage.md as the public-facing entry point for the rendered wiki and linked it from wiki/index.md so future publication work has a clear landing page distinct from the internal index.

Why it matters:

This gives the eventual Hugo publication layer a dedicated front door without changing the canonical internal wiki directory structure.

[2026-04-23] restructure | Hugo publication adapter

Added the first publish/ adapter for the wiki, including Hugo mounts, minimal site templates, and the rendered-homepage wiring needed for local preview with hugo server.

Created or updated:

• publish/hugo.toml
• publish/layouts/_default/baseof.html
• publish/layouts/_default/list.html
• publish/layouts/_default/single.html
• publish/layouts/index.html
• wiki/homepage.md
• wiki/overview.md
• README.md

Why it matters:

This turns the wiki from a content-only repository into a site that can be previewed locally and later wired into the same deployment chain used by the blog, without restructuring the source wiki tree.

[2026-04-23] restructure | PaperMod theme adoption

Installed PaperMod as a Git submodule under publish/themes/ and switched the Hugo adapter to use the theme directly, keeping only the homepage override needed to preserve homepage.md as the public landing page.

Created or updated:

• .gitmodules
• publish/themes/PaperMod
• publish/hugo.toml
• publish/layouts/index.html

Why it matters:

This aligns the wiki publication path with the blog’s theme-management model while keeping the adapter minimal and easier to maintain than a hand-rolled full layout stack.

[2026-04-23] restructure | PaperMod visual refinement

Adjusted the wiki presentation layer so PaperMod behaves like a documentation site instead of a generic blog: stronger link contrast, fixed light theme, cleaner section cards, a more serious homepage, and no duplicate listing appended under the main wiki index.

Created or updated:

• publish/hugo.toml
• publish/assets/css/extended/wiki.css
• publish/layouts/index.html
• publish/layouts/_default/list.html

Why it matters:

This makes the rendered wiki materially easier to scan and navigate, fixes low-visibility links, and gives the public surface a more professional documentation-oriented visual language.

[2026-04-23] restructure | wiki image publication pipeline

Added the container build and GitHub Actions publication path for the wiki, mirroring the blog’s delivery pattern while building from the publish/ adapter and publishing to the dedicated tazzo/tazlab-wiki image stream.

Created or updated:

• Dockerfile
• .dockerignore
• .github/workflows/publish.yml

Why it matters:

This gives the wiki a production-ready image publication lane that matches the existing blog deployment model and keeps the Docker Hub credential contract aligned on the same GitHub Actions secret name used by the blog.

[2026-04-23] fix | wiki Docker build git metadata

Disabled enableGitInfo in publish/hugo.toml so the containerized Hugo build no longer tries to read .git metadata that is not copied into the wiki image build context.

Created or updated:

• publish/hugo.toml

Why it matters:

This removes the failed to load Git data buildx failure in GitHub Actions and lets the wiki image publish from the Docker build path without bundling the repository history into the image.

[2026-04-23] restructure | deep Ephemeral Castle documentation expansion

Performed a comprehensive documentation sweep of the ephemeral-castle repository, creating a modular and granular manual for future agents.

Created or updated:

• wiki/entities/ephemeral-castle.md (Hub centralizzato)
• wiki/topics/ephemeral-castle-architecture.md
• wiki/topics/ephemeral-castle-terragrunt-layers.md
• wiki/topics/ephemeral-castle-rebirth-protocol.md
• wiki/topics/ephemeral-castle-vault-runtime-architecture.md
• wiki/topics/ephemeral-castle-vault-bootstrap-and-restore.md
• wiki/topics/ephemeral-castle-tailnet-security.md
• wiki/topics/ephemeral-castle-tailscale-bridge.md
• wiki/operations/ephemeral-castle-commands.md
• wiki/index.md

Why it matters:

This provides a complete technical operational context for agents, allowing them to understand the Terragrunt layer model, the Vault runtime lifecycle on Hetzner, and the Tailscale mesh security without having to reverse-engineer the entire codebase or read obsolete documents.

[2026-04-23] restructure | deep TazLab K8s documentation sweep

Performed a comprehensive documentation sweep of the tazlab-k8s GitOps repository, detailing the layering pattern, image automation, and secret delivery model.

Created or updated:

• wiki/entities/tazlab-k8s.md (Hub centralizzato)
• wiki/topics/tazlab-k8s-structure.md
• wiki/topics/tazlab-k8s-image-automation.md
• wiki/topics/tazlab-k8s-secrets-mapping.md
• wiki/topics/tazlab-k8s-ingress-and-auth.md
• wiki/topics/tazlab-k8s-monitoring.md
• wiki/index.md

Why it matters:

This ensures that any agent working on the cluster has a clear understanding of the GitOps workflow, how to safely add new applications, and how secrets are injected without exposing them in manifests.

[2026-04-23] restructure | deep TazPod documentation sweep

Completed the operational manual by documenting the tazpod operator environment, its container architecture, and the sensitive vault-unseal mechanism.

Created or updated:

• wiki/entities/tazpod.md (Hub centralizzato)
• wiki/topics/tazpod-architecture.md
• wiki/topics/tazpod-vault-mechanism.md
• wiki/operations/tazpod-cli-reference.md
• wiki/index.md

Why it matters:

This provides the final piece of the onboarding puzzle for new agents, explaining how to maintain their own secrets, recover the environment from S3, and use the TazPod toolchain to interact with the rest of the TazLab infrastructure.

[2026-04-23] restructure | deep TazLab K8s GitOps manual expansion

Completed the GitOps manual by documenting the Flux DAG, repository structure, operator inventory, and cold-start logic.

Created or updated:

• wiki/topics/tazlab-k8s-flux-dag.md
• wiki/topics/tazlab-k8s-repository-mapping.md
• wiki/topics/tazlab-k8s-operators-inventory.md
• wiki/topics/tazlab-k8s-bootstrap-logic.md
• wiki/topics/tazlab-k8s-conventions.md
• wiki/index.md

Why it matters:

This provides a detailed technical reference for the cluster’s desired state, allowing future agents to navigate the GitOps dependency graph, troubleshoot reconciliation issues, and correctly add or modify infrastructure operators and application manifests.

[2026-04-23] restructure | deep TazPod manual expansion

Completed the operator documentation by secluding the tazpod repository into granular topics covering image layering, the RAM-only security model, and nomadic recovery workflows.

Created or updated:

• wiki/topics/tazpod-image-hierarchy.md
• wiki/topics/tazpod-vault-security.md
• wiki/topics/tazpod-nomadic-recovery-flow.md
• wiki/topics/tazpod-provisioning-and-dotfiles.md
• wiki/topics/tazpod-sync-daemon.md
• wiki/index.md

Why it matters:

This provides a definitive technical manual for the operator environment, ensuring that any future agent understands how to recover from scratch, how secrets are protected in memory, and how the containerized toolchain is provisioned and kept in sync with S3.

[2026-04-25] refine | high-definition TazPod manual revision

Reworked the canonical tazpod pages to align them with the actual Go command dispatch, vault paths, S3 contract, Docker layer chain, and .bashrc provisioning logic instead of relying on older generalized summaries.

Created or updated:

• wiki/topics/tazpod-architecture.md
• wiki/topics/tazpod-image-hierarchy.md
• wiki/topics/tazpod-vault-security.md
• wiki/topics/tazpod-nomadic-workflow.md
• wiki/topics/tazpod-provisioning-and-dotfiles.md
• wiki/topics/tazpod-sync-daemon.md
• wiki/operations/tazpod-cli-reference.md
• wiki/entities/tazpod.md
• wiki/index.md

Why it matters:

The tazpod section now explains the actual runtime contract, command dispatch, persistence boundaries, cryptographic model, and operator recovery flow with enough fidelity that an agent can reason directly from the wiki before opening the code.

[2026-04-25] restructure | tailnet startup and verification path

Documented the non-interactive Tailscale startup flow and the verified peer reachability checks in both the Ephemeral Castle provider context and the wiki runbook/security pages.

Created or updated:

• AGENTS.ctx/ephemeral-castle/CONTEXT.md
• wiki/operations/ephemeral-castle-commands.md
• wiki/topics/ephemeral-castle-tailnet-security.md

Why it matters:

This preserves the working tailnet join path that avoids an interactive login prompt, and it gives future operators a single documented entrypoint plus concrete ping targets for vault and cluster reachability.

[2026-04-26] ingest | Vault API access contract

Documented the Hetzner Vault API access pattern in wiki/topics/tazlab-secret-and-identity-flow.md and wiki/topics/ephemeral-castle-vault-runtime-architecture.md: Vault is reachable over Tailscale at https://lushycorp-api.ts.tazlab.net:8200, but helper tooling still authenticates with a Vault token, with the current canonical operator token sourced from ~/secrets/lushycorp-vault/admin-token.txt. This matters because the migration helper needs a durable, explicit contract and should not assume network access alone is sufficient.

[2026-04-26] ingest | Infisical source-side bootstrap contract

Updated wiki/topics/tazlab-k8s-secrets-mapping.md to record the current Infisical bootstrap inputs for tazlab-secrets: ~/secrets/infisical-client-id and ~/secrets/infisical-client-secret, with the source scope inherited from the ephemeral-castle live/env.hcl contract. This matters because the one-key migration helper needs a concrete source-auth contract as well as a destination-auth contract.

[2026-04-26] ingest | Infisical source-folder derivation

Clarified in wiki/topics/tazlab-k8s-secrets-mapping.md that the migration helper should infer the Infisical source folder from the existing bundle mapping table instead of asking the operator for an extra runtime argument. This matters because the helper contract stays minimal while still remaining deterministic.

[2026-04-27] query | Vault cluster-side reachability contract

Updated wiki/topics/ephemeral-castle-tailscale-bridge.md, wiki/topics/tazlab-secret-and-identity-flow.md, and wiki/topics/ephemeral-castle-vault-runtime-architecture.md after live verification from the cluster and the dedicated Tailscale tool session. The verified result is that cluster pods can already reach the Vault tailnet IP through the Talos node bridge, and HTTPS works when the request uses explicit SNI/host mapping, but workload DNS for lushycorp-api.ts.tazlab.net is not yet wired by the bridge alone. This matters because the Vault migration track is blocked not on raw pod-to-tailnet egress, but on the remaining cluster DNS / hostname contract required by ESO.

[2026-04-27] query | Vault native Tailscale hostname direction

Refined wiki/topics/ephemeral-castle-vault-runtime-architecture.md and wiki/topics/tazlab-secret-and-identity-flow.md with the code-verified distinction between the native Tailscale host identity lushycorp-vm.ts.tazlab.net and the custom runtime alias lushycorp-api.ts.tazlab.net. This matters because the preferred future architecture is to converge the Vault API/TLS contract onto the Tailscale-owned hostname rather than keep carrying custom DNS glue around a non-native alias.

Updated wiki/topics/ephemeral-castle-tailscale-bridge.md too so the bridge page now makes the same distinction explicitly and does not imply that the custom Vault alias is part of the Tailscale-owned naming surface.

[2026-04-28] query | Vault destroy/create matrix and bootstrap-anchor gap

Updated wiki/topics/ephemeral-castle-vault-bootstrap-and-restore.md, wiki/topics/ephemeral-castle-vault-runtime-architecture.md, wiki/topics/ephemeral-castle-hetzner-vault-runtime.md, and wiki/operations/ephemeral-castle-commands.md after the live Phase-1 validation pass for 09-vault-k8s-integration-prep. The durable findings are that the old C2 matrix still governs current behavior, T0 + H0 + S1 is an intentional hard-fail state, create-time validation depends on a live operator-side Tailscale session, and the runtime classifies TazPod state from ~/secrets/lushycorp-vault/ rather than from /workspace/.tazpod/vault/vault.tar.aes directly. This matters because the missing operator-side canonical bootstrap files, not a broken matrix, are what currently block a deterministic destroy/create completion.

[2026-04-28] query | Encrypted vault archive content check

Extended wiki/topics/ephemeral-castle-vault-bootstrap-and-restore.md after a direct decrypted inspection of /workspace/.tazpod/vault/vault.tar.aes. The verified result is that the current encrypted archive predates the April C1/C2 Vault work and contains zero lushycorp-vault/* entries, so the bootstrap-anchor gap is not caused by a bad unlock/materialization step; the active encrypted archive itself never captured the canonical Vault bootstrap set.

[2026-04-28] query | Missing tazpod save/push after Vault Phase B

Extended wiki/topics/ephemeral-castle-vault-bootstrap-and-restore.md again after a code audit of the Vault runtime role and tazpod vault implementation. The verified result is that the runtime does write canonical Vault artifacts into ~/secrets/lushycorp-vault/ during Phase B, but nowhere in the C1/C2 flow does it run tazpod save plus tazpod push vault. This matters because it identifies the real root cause: the operator-side RAM secrets were updated, but the encrypted archive backing future unlocks was never refreshed.

[2026-04-28] query | Vault persistence remediation and runtime re-stabilization

Updated wiki/topics/ephemeral-castle-vault-bootstrap-and-restore.md and wiki/topics/ephemeral-castle-vault-runtime-architecture.md after the runtime persistence fix and live recovery pass. The durable result is that the runtime flow now asserts the RAM vault is really mounted and runs tazpod save / tazpod push vault from /workspace, while the live environment was repaired so the encrypted operator archive again contains the full lushycorp-vault/* canonical set and the remote snapshot lineage was reinitialized under 61e17cbf-f522-4825-9bfe-444373173650. The same pass also surfaced two residual tazpod UX bugs: save can look successful when the RAM mount is absent, and push is cwd-sensitive if called outside the workspace root.

[2026-04-29] detail | mnemosyne-mcp-server debts

Created a dedicated debt detail page for mnemosyne-mcp-server documenting all known code-level gaps found during the Section 4 wiki-archivist survey review.

Created or updated:

• wiki/details/mnemosyne-mcp-debts-detail.md — TD-002, async ingestion error swallowing, unreachable temporal filters, unbounded dedup cache, missing graceful shutdown, no HTTP auth, root path serving MCP traffic, Python tool gaps
• wiki/entities/mnemosyne-mcp-server.md — added Known Issues / Technical Debt section linking to the new detail page
• wiki/index.md — added Details section

Why it matters:

This anchors the wiki’s technical debt documentation model: instead of burying known issues in generic architecture pages, each area gets a dedicated debt detail page that cross-references the canonical TD register in memory, the AGENTS.ctx context, and the specific source code paths. Agents navigating the wiki can immediately see what is broken or risky in an area without reading the full implementation.

[2026-04-29] detail | mnemosyne-mcp-server section completed

Completed Section 4 of the wiki-archivist survey plan: created all 5 remaining missing pages and updated the entity hub following the standard Level 1 template.

Created or updated:

• wiki/topics/mnemosyne-database-schema.md — NEW: database schema, pgvector queries, dimension auto-detection
• wiki/details/mnemosyne-ingest-memory-detail.md — NEW: exact ingestion pipeline with code paths
• wiki/details/mnemosyne-retrieve-memories-detail.md — NEW: semantic search flow and temporal filter gap
• wiki/details/mnemosyne-deployment-detail.md — NEW: Docker, CI/CD, Flux automation, cluster manifests
• wiki/details/mnemosyne-python-tools-detail.md — NEW: chronicler.py, gather_sessions.py
• wiki/entities/mnemosyne-mcp-server.md — UPDATED: added repository structure, quick facts, canonical starting pages
• wiki/index.md — UPDATED: added Knowledge Systems topic section and 4 new detail entries

Why it matters:

Section 4 was previously marked “Completed” in the survey state but only 6 of 11 planned pages existed. The 5 missing pages included the database schema topic and 4 Level 3 detail pages. The entity hub also lacked standard Level 1 sections. This pass closes all gaps and fixes broken cross-links from the existing topic pages to the newly created details.

[2026-04-29] detail | tazlab-k8s Flux section (Section 3 — Flux scope)

Created and updated pages for the Flux/GitOps scope of Section 3 in the wiki-archivist survey plan.

Created:

• details/tazlab-k8s-flux-kustomizations-detail.md — All 12 Flux Kustomizations with exact spec, wait policy, dependencies, timeout, health checks
• details/tazlab-k8s-image-automation-detail.md — 4 image automation pipelines (blog, wiki, mcp, openclaw) with tag patterns and commit strategy

Updated:

• entities/tazlab-k8s.md — Full Level 1 hub: repository structure, quick facts, canonical starting pages, relationships
• topics/tazlab-k8s-flux-dag.md — Corrected wait policy truth table, added apps-openclaw, fixed misleading “wait: false from Level 3 onwards” statement, added health checks section
• topics/tazlab-k8s-operators-inventory.md — Added missing operators (dex, OAuth2 Proxy, cloudflare-ddns, pgadmin, homepage, metrics-server), namespace inventory table
• wiki/index.md — Added 2 new detail entries

Why it matters:

The existing flux-dag page had drifted from the actual Kustomization manifests: it incorrectly stated that all Level 3+ Kustomizations use wait: false (in reality, only infrastructure-instances does; apps-openclaw and infrastructure-auth use wait: true). The operators inventory was missing 5 controllers and had no namespace inventory. Both are now aligned with the code.

[2026-04-29] detail | tazlab-k8s Section 3 completed

Completed the remaining operator/app detail pages, reference pages, and Level 4 docs for tazlab-k8s.

Created:

• details/tazlab-k8s-cert-manager-detail.md — ClusterIssuers, certificate lifecycle, Cloudflare DNS01
• details/tazlab-k8s-traefik-detail.md — HelmRelease, LoadBalancer, middlewares, ingress class
• details/tazlab-k8s-external-secrets-detail.md — All ExternalSecrets inventory, templates
• details/tazlab-k8s-tazlab-db-detail.md — PostgresCluster, databases, init SQL, S3 backup
• details/tazlab-k8s-dex-oauth2-detail.md — Dex OIDC, OAuth2 Proxy, ForwardAuth middleware
• details/tazlab-k8s-hugo-blog-detail.md — Deployment, redirect ingress, certificate, image automation
• details/tazlab-k8s-hugo-wiki-detail.md — Wiki deployment, TLS, delivery chain
• details/tazlab-k8s-monitoring-detail.md — kube-prometheus-stack, Grafana PostgreSQL backend, dashboards
• details/tazlab-k8s-openclaw-detail.md — AI agent, network policy, PVCs, TD-019
• references/tazlab-k8s/flux-kustomization-example.md — Annotated Kustomization YAML
• references/tazlab-k8s/image-policy-example.md — Full ImagePolicy pipeline example
• references/tazlab-k8s/external-secret-example.md — Three ExternalSecret variants
• references/tazlab-k8s/kustomize-layering.md — Base/cluster overlay pattern

Updated:

• wiki/index.md — Added 13 new detail + reference entries

Total: 13 new pages created, 3 existing pages updated, all cross-linked correctly.

[2026-04-29] detail | tazpod Section 1 completed

Completed Section 1 (tazpod) of the wiki-archivist survey plan: 9 Level 3 details, 7 Level 4 references, updated hub and 3 topic/operation pages.

Created:

• details/tazpod-smart-entry-detail.md — Flow diagram, branch conditions, code paths
• details/tazpod-vault-lifecycle-detail.md — unlock/lock/save/push/pull, AWS bridge, SetupIdentity
• details/tazpod-sync-daemon-detail.md — 5-min cycle, SIGTERM, log path, failure model
• details/tazpod-container-lifecycle-detail.md — Docker flags, state machine, MTU issue
• details/tazpod-dotfiles-detail.md — bashrc, tmux, symlinks, OpenCode seeding
• details/tazpod-config-detail.md — All Config struct fields with defaults
• details/tazpod-crypto-detail.md — AES-256-GCM, PBKDF2, output format
• details/tazpod-s3-detail.md — S3 client, vault object contract, cwd sensitivity
• details/tazpod-ci-detail.md — Build matrix, conditional Docker pipeline
• references/tazpod/config-yaml-example.md, dockerfile-* (4), bashrc-full.md, taskfile-yml.md
• entities/tazpod.md — Full hub with repo structure, quick facts, canonical pages, TD table

Updated:

• operations/tazpod-cli-reference.md — Added missing commands, flag tables, exit codes
• topics/tazpod-sync-daemon.md — Added 5-min interval, SIGTERM, log path
• topics/tazpod-vault-security.md — Added TD-022, TD-021 references
• topics/tazpod-architecture.md — Added links to all new detail pages
• wiki/index.md — Added 16 new entries + new References subsection

Total: 16 new pages (9 detail + 7 reference), 5 existing pages updated.

[2026-04-29] detail | tailscale Section 7 completed

Completed Section 7 (tailscale networking) of the wiki-archivist survey plan: 4 Level 2 topics, 5 Level 3 details, 3 Level 4 references, updated hub and 2 existing pages.

Created:

• entities/tailscale.md — Full hub: network segments, vault hostname evolution, quick facts, known issues
• topics/tailscale-iac-management.md — Terraform provider, OAuth client model, ACL as code
• topics/tailscale-operator-connectivity.md — Userspace daemon, auth key minting, restart after container
• topics/tailscale-cluster-integration.md — Talos System Extension, raw IP vs DNS gap
• topics/tailscale-vault-contract.md — Vault hostname evolution, MagicDNS convergence, TD-020
• details/tailscale-terraform-root-detail.md — Resource inventory, variables, outputs
• details/tailscale-acl-policy-detail.md — Tag ownership, ACL diagram, SSH access
• details/tailscale-oauth-client-detail.md — Key minting flow, fallback, key properties
• details/tailscale-talos-bridge-detail.md — System Extension config, AuthKey injection
• details/tailscale-magicdns-detail.md — Naming contracts, custom alias pitfalls
• references/tailscale/acl-json.md — Current ACL policy
• references/tailscale/terraform-main-tf.md — Terraform root module
• references/tailscale/start-sh.md — Operator daemon start script

Updated:

• topics/ephemeral-castle-tailnet-security.md — Replaced stale hostname lushycorp-vm-ts-tazlab-net-3 with current lushycorp-vault, added vault hostname note, links to new pages
• topics/ephemeral-castle-tailscale-bridge.md — Updated verification with current FQDN and tailnet IP, corrected custom alias explanation
• wiki/index.md — Added Tailscale Networking section, 5 new details, 3 references

[2026-04-29] detail | blog-src Section 5 completed

Completed Section 5 (blog-src) of the wiki-archivist survey plan: 4 Level 2 topics, 3 Level 3 details, updated hub.

Created:

• entities/blog-src.md — Full hub: repo structure, quick facts, canonical pages
• topics/blog-publication-pipeline.md — Multi-step GitOps publication chain
• topics/blog-content-structure.md — Article organization, front matter, bilingual model
• topics/blog-comments-system.md — Cusdis Cloud, bilingual threads, future self-hosted
• topics/blog-theme-management.md — Blowfish versioning, pinning, config sections
• details/blog-post-workflow-detail.md — 5-phase writing workflow, prompt files, image processing
• details/blog-hugo-config-detail.md — Site, language, theme configuration reference
• details/blog-ci-detail.md — GitHub Actions pipeline, tag strategy, delivery chain

[2026-04-29] detail | ephemeral-castle Section 2 completed

Completed Section 2 (ephemeral-castle + vault) of the wiki-archivist survey plan: 8 Level 3 details, 5 Level 4 references, updated hub and 2 existing pages.

Created:

• entities/ephemeral-castle.md — Full hub: repo structure, quick facts, canonical pages, TD table
• details/ephemeral-castle-create-destroy-detail.md — 6-stage create pipeline, destroy process, preflight checks
• details/ephemeral-castle-ansible-vault-detail.md — Classification, guards, execution, post-convergence
• details/ephemeral-castle-terraform-modules-detail.md — 6 modules, build order
• details/ephemeral-castle-terragrunt-layers-detail.md — Dependency chain, env.hcl, secret injection
• details/ephemeral-castle-vault-ansible-scripts-detail.md — phase-a-bootstrap, unseal, backup, restore
• details/ephemeral-castle-vault-systemd-detail.md — 5 systemd units, Quadlet TD-016
• details/ephemeral-castle-golden-image-detail.md — Builder pipeline, v1-v4 history
• details/ephemeral-castle-proxmox-cluster-detail.md — create/destroy/nuclear-wipe/stress-test
• references/ephemeral-castle/vault-hcl-template.md
• references/ephemeral-castle/create-sh-stages.md
• references/ephemeral-castle/ansible-inventory.md
• references/ephemeral-castle/env-hcl.md
• references/ephemeral-castle/vault-certs-fetch.md

Updated:

• topics/ephemeral-castle-vault-runtime-architecture.md — Added TD links and detail page references
• operations/ephemeral-castle-commands.md — Added Ansible playbooks, golden-image build, corrected ping targets
• wiki/index.md — Added 8 new details, 5 references

Total: 15 new pages, 2 existing pages updated. Section 2 fully completed.

[2026-04-29] detail | agents-ctx Section 6 + cross-cutting Section 8 completed

Final two sections completed. Created 22 pages total.

Section 6 (agents-ctx):

• entities/agents-ctx.md — Full hub with context registry and canonical pages
• 5 Level 2 topics: context-system, memory-system, crisp-methodology, pi-council, wiki-archivist
• 3 Level 3 details: archive-flow, crisp-workflow, memory-files

Section 8 (cross-cutting + blog ingestion):

• concepts/zero-trust-architecture.md — Security model across all layers
• concepts/nomadic-operator.md — Portable operator identity
• topics/tazlab-operating-model.md — Repository roles in daily work
• 7 blog source ingestion pages: ephemeral-castle-vision, tazpod-rising, tazpod-v2-ram-vault, bootstrap-from-zero, phoenix-protocol, immutable-handover, terragrunt-pivot

Total survey complete: 8 sections, all pages created and cross-linked.

[2026-04-30] query | Transport root cause confirmed, TUN mode adopted, split playbooks, timing improvement

Updated wiki pages after the TazPod hostnet+TUN runtime confirmed that the remaining Hetzner Vault create pipeline failures were caused by the old Docker userspace-networking + tailscale nc transport path, not by Vault/Ansible logic. The full create cycle now runs in ~344s (down from ~1200s).

Updated:

• topics/tailscale-operator-connectivity.md — Added Host Network + TUN Mode section documenting --network host, --cap-add NET_ADMIN, /dev/net/tun, tazpod-tailscale-up, TAILSCALE_SOCKET auto-detection, render-tailscale-inventory.sh TUN auto-detection, and the performance improvement.
• operations/ephemeral-castle-commands.md — Replaced monolithic vault-s3-backup-recovery.yml with 3 split playbooks (install/converge/post), added new phase log patterns (*-60-vault-runtime-install.log, *-70-vault-runtime-converge.log, *-80-vault-runtime-post.log), updated preflight to note that hostnet+TUN mode runs Tailscale natively via tazpod-tailscale-up, added 344s timing table.
• entities/ephemeral-castle.md — Added TD-024 (Closed) to Known Issues, updated vault tailnet IP to 100.82.13.87, updated create.sh description to “8-stage provisioning pipeline (~344s)”, added playbook names to ansible entry.
• wiki/index.md — Updated tailscale-operator-connectivity description to reflect both modes.

Why it matters: The transport-layer root cause is now confirmed and resolved. The wiki should teach future operators that the old userspace path is deprecated and that hostnet+TUN is the default, faster, and more reliable runtime mode.

[2026-05-02] update | tazpod v0.3.21 — vault auto-lock, vault CLI, KUBECONFIG

Updated:

• entities/tazpod.md — version 0.3.18 → 0.3.21, added TD-027 to Known Issues
• topics/tazpod-image-hierarchy.md — added vault CLI and KUBECONFIG ENV to k8s layer
• details/tazpod-dotfiles-detail.md — replaced stale tazpod() wrapper, added vault_maybe_lock trap section with reference counting, added auto-load on shell start
• details/tazpod-vault-lifecycle-detail.md — added auto-lock on last shell exit section, TD-027 regression analysis
• wiki/log.md — this entry

Why it matters: The vault auto-lock regression had two cumulative root causes going back months. Documenting the trap + reference counting fix and the multi-shell behavior ensures operators understand how the vault lifecycle works and why it only locks on the last exit.

[2026-05-03] update | tazpod v0.3.22 — final marker-file vault auto-lock

Updated:

• entities/tazpod.md — version 0.3.21 → 0.3.22, TD-027 summary corrected to marker-file final fix
• details/tazpod-dotfiles-detail.md — replaced stale pgrep trap with final marker-file implementation in /tmp/.tazpod-shells/
• details/tazpod-vault-lifecycle-detail.md — updated auto-lock section to final v0.3.22 design and history
• wiki/log.md — append entry

Why it matters: The earlier pgrep-based shell counting was not resistant enough to real operator behavior (background subshells, orphaned docker exec sessions, repeated container rebuild tests). The final marker-file approach is simpler to reason about, survives stale-process cleanup, and matches the desired rule: first exit of multiple shells does nothing, last exit locks the vault.

[2026-05-05] update | CRISP 07-tailscale-operator-deployment split → wiki alignment

Updated wiki to reflect the CRISP project split of 07-tailscale-operator-deployment into two subprojects:

• 10-operator-dns-resolution — Tailscale Kubernetes Operator bootstrap + MagicDNS resolution (magellanic-gondola.ts.net) for cluster pods, via DNSConfig + CoreDNS forwarding. Hard prerequisite for 09-vault-k8s-integration-prep Phase 2.
• 20-tailscale-service-exposure — Postgres tailnet exposure, admin dashboard migration. Deferred until after Vault migration (09/10).

Updated:

• entities/tailscale.md — Added k8s_operator OAuth client (tag tag:k8s-operator, scope devices), Tailscale Kubernetes Operator section, updated Quick Facts
• topics/tailscale-cluster-integration.md — Updated Connectivity Model with DNS resolution path diagram, documented CoreDNS hostNetwork constraint and Operator DNS solution
• topics/tazlab-k8s-operators-inventory.md — Added Tailscale Operator as #14 with HelmRelease details, added tailscale namespace to inventory
• entities/tazlab-k8s.md — Added tailscale/ to operators/core/, configs/, and DNSConfig to bridge/ in directory tree
• topics/tazlab-crisp-program-map.md — Updated 30-hetzner-vault-consumers section with 07 split and child project descriptions
• topics/tailscale-vault-contract.md — Split cluster pod path into current (IP-only with CoreDNS constraint) and planned (Operator DNS resolution)
• wiki/log.md — this entry

Why it matters: The 07 split mirrors a real architectural decision (MagicDNS resolution via Operator DNS + CoreDNS forwarding, avoiding hostNetwork and Talos machine config changes). The wiki must reflect the planned state so future agents and operators understand the DNS architecture before crisp-build executes the plan.

[2026-05-07] update | antigravity plugin removed

Removed all antigravity (opencode-antigravity-auth@beta) references from the wiki after the plugin was purged from the TazPod runtime and image due to ToS violation risk.

Updated:

• details/tazpod-dotfiles-detail.md — removed antigravity.json seed and npm install steps from OpenCode auto-seeding section
• references/tazpod/bashrc-full.md — replaced the antigravity opencode.json/antigravity.json block with standard model config
• topics/tazpod-provisioning-and-dotfiles.md — removed antigravity seed steps, added removal note
• wiki/log.md — this entry

Why it matters: The antigravity plugin was removed from both the current runtime and the tazpod .bashrc provisioning so it will not reappear on next container restart. The wiki must reflect the current provisioning state to avoid teaching operators about a removed component.

[2026-05-08] ingest | Tailscale Operator DNS, create.sh hardening, Infisical EU endpoint

Updated pages with findings from the 10-operator-dns-resolution build session (8 destroy/create cycles).

Created/Updated:

• topics/tailscale-cluster-integration.md — Replaced “Planned” DNS path with deployed solution: hostNetwork CoreDNS relay DaemonSet (port 5353), static hosts mapping for Vault, note about DNSConfig limitation (operator-proxy names only)
• topics/ephemeral-castle-rebirth-protocol.md — Added ghcr pull secret section, CoreDNS MagicDNS patch section, storage parallelization note, TD-026 auth race, documented log locations
• topics/tazlab-k8s-operators-inventory.md — Tailscale Operator updated from “Planned” to “Deployed 2026-05-08” with 3-layer Flux DAG details
• topics/tazlab-k8s-secrets-mapping.md — Added Infisical EU endpoint (eu.infisical.com), project slug, secrets path
• wiki/log.md — this entry

Why it matters: The cluster bootstrap process was hardened against ghcr.io anonymous rate limits, CoreDNS inlineManifest overwrites, and sequential layer bottlenecks. The Tailscale Operator DNS path was corrected after discovering DNSConfig only resolves operator-managed proxy names. The Infisical EU endpoint was discovered (setup.sh and ESO were configured with the wrong region endpoint). Auth race against Dex documented as TD-026.

[2026-05-09] review | tailscale + tazlab-k8s post Tailscale Operator deployment

Review pass after Tailscale Operator deployment (2026-05-08). Updated stale wiki pages to reflect live cluster state.

Updated:

• entities/tailscale.md — K8s Operator da Planned a Deployed, k8s_operator OAuth aggiornato, Quick Facts corretti
• topics/tazlab-k8s-flux-dag.md — 12→15 Kustomizations, aggiunto ramo Tailscale (3-layer DAG), livelli rinumerati (da 4 a 5)
• details/tazlab-k8s-flux-kustomizations-detail.md — inventory da 12 a 15, DAG diagram con ramo Tailscale, 3 nuove schede (infrastructure-tailscale, operators-tailscale, tailscale-dns), wait table aggiornata
• topics/tailscale-vault-contract.md — sezione “planned: DNS resolution” → “deployed 2026-05-08: DNS relay”
• details/tailscale-magicdns-detail.md — gap risolto dal DNS relay, documentato flusso pod DNS e limitazione DNSConfig
• AGENTS.ctx/crisp/CONTEXT.md — registry: 10-operator-dns-resolution da Draft a Completed

Why it matters: La wiki diceva ancora “Planned”/“Draft”/“12 Kustomizations” mentre il Tailscale Operator è deployato su cluster dal 2026-05-08 con 3 nuove Kustomization e DNS relay funzionante. Il review allinea la documentazione alla realtà del codice.

[2026-05-15] restructure | new Hermes Agent section

Created the Hermes Agent section for the new Proxmox LXC deployment (ephemeral-castle/hermes/). Hermes was implemented after the last wiki survey (2026-04-29) and had no wiki coverage.

Created:

• entities/hermes.md — Entity hub with repo structure, quick facts, canonical pages, relationships
• topics/hermes-lxc-deployment.md — Level 2 topic: architecture, design decisions, iteration history, storage model, lifecycle timing

Updated:

• entities/ephemeral-castle.md — Added hermes/ to repository structure, added hermes relationship
• wiki/index.md — Added hermes entity entry and new “AI Agent Services” topic section

[2026-05-15] update | Hermes Agent — Pet vs Cattle persistence pattern

Updated wiki to reflect the final persistence architecture: CT 999 (pet) owns the 10G volume, CT 105 (cattle) mounts it via API. Replaced backup/restore references with the Pet vs Cattle pattern.

Pages updated:

• entities/hermes.md — Full rewrite with Pet vs Cattle architecture, both CT IDs, research assets references
• topics/hermes-lxc-deployment.md — Full rewrite: new lifecycle timings (137s), research history, API call references

[2026-05-16] detail | tazpod code structure page

Created a new Level 3 detail page documenting the tazpod Go source code structure after a full source read pass.

Created:

• details/tazpod-code-structure-detail.md — Package tree, file-by-file function inventory (all 8 files), dispatch table, key call chains (up, smartEntry, unlock, save+push), cross-file dependencies, 10 code-encoded architectural decisions, known issues table

Updated:

• entities/tazpod.md — Added Code Structure Detail to CLI & Container Lifecycle canonical pages
• topics/tazpod-architecture.md — Added child link to Code Structure Detail
• wiki/index.md — Added new detail entry
• wiki/log.md — this entry

Why it matters: The wiki had 9 Level 3 detail pages and 7 Level 4 reference pages for tazpod covering lifecycle, vault, config, crypto, S3, CI, smart entry, and dotfiles, but no page documented the actual Go code structure itself — how main.go dispatches, how the 8 files relate, what the internal packages contain, and what the full call chains look like. This page fills that gap as the definitive code-navigation map.

[2026-05-20] forge | tazpod

Forged the TazPod Development & Hardening context.

Created:

• wiki/contexts/tazpod-context.md — Pre-built operational context file.

Updated:

• wiki/contexts/INDEX.md — Added the new context to the catalog index.
• wiki/log.md — this entry.

Why it matters: This establishes the tazpod development and hardening context as a self-contained brief, indexing all relevant wiki pages, memory items, open technical debts, and CRISP project dependencies to make it immediately operational for execution.

[2026-05-20] update | tazpod v0.3.30 — Antigravity CLI and persistence

Updated:

• entities/tazpod.md — Current version bump to 0.3.30.
• details/tazpod-dotfiles-detail.md — Added .antigravity and .antigravitycli to the persistent symlinks table.
• wiki/log.md — this entry.

Why it matters: TazPod was updated to v0.3.30 by adding the Antigravity CLI to the AI Docker layer (Dockerfile.ai) and extending .bashrc bootstrap script to mount .antigravity (settings/extensions) and .antigravitycli (trusted workspace registrations) folders persistently under /workspace/.tazpod/. This ensures the AI agent state is preserved across container restarts.

[2026-05-20] update | tazpod vault S3 history design

Updated wiki pages with the tazpod-vault-s3-history CRISP project design: S3 history key structure, content-hash skip logic, retention policy (N=50), TD-022 fix (vaultFilePath dual-path), pull –index, and list vault-history.

Updated:

• details/tazpod-s3-detail.md — added History Copies section, new S3 Methods table, fixed TD-022 section, updated Vault Object Contract
• details/tazpod-vault-lifecycle-detail.md — updated push/pull/save sections with content-hash, –index, history/retention
• details/tazpod-sync-daemon-detail.md — added note that history is manual-only, daemon does not produce history

Why it matters: Documents the full design for the upcoming feature, including the content-hash skip trick (hash plaintext before encryption to avoid salt/nonce noise) and the dual-path resolution that works from both container and host.

[2026-05-20] forge | lushycorp-vault

Forged the LushyCorp Vault Runtime operational context.

Created:

• wiki/contexts/lushycorp-vault-context.md — Pre-built operational context for Hetzner Vault runtime.

Updated:

• wiki/contexts/INDEX.md — Added the new context to the catalog index.
• wiki/log.md — this entry.

Why it matters: This establishes the LushyCorp Vault runtime context as a self-contained brief, indexing all relevant wiki pages (vault architecture, bootstrap & restore, create/destroy lifecycle, Tailscale contract), memory items (chronicle entries for Phase 1/2, TD-016/020/021/022), and CRISP project dependencies (09-vault-k8s-integration-prep, 15-tailscale-operator-hardening, 10-operator-dns-resolution) to make it immediately operational for execution.

[2026-05-21] update | wiki allineamento Vault — 09 Phase 2

Updated 4 pages and the index after verifying prerequisites for 09-vault-k8s-integration-prep Phase 2:

Updated:

• wiki/topics/tailscale-vault-contract.md — rimosse sezioni obsolete (relay DaemonSet, IP-only path). Aggiunta architettura ExternalName egress proxy, CoreDNS Disable&Replace, Migration Direction con Phase 1 ✅ / Phase 2 🔄 / Phase 3.
• wiki/details/tailscale-magicdns-detail.md — sostituita sezione relay DaemonSet con ExternalName + DNSConfig (architettura corrente). Aggiunto CoreDNS Hardening su Talos, nota “Previous Approach (decommissioned)”.
• wiki/entities/hashicorp-vault.md — reso operativo: tabella stato layer, CRISP projects table, link a tutti i topic correlati.
• wiki/topics/ephemeral-castle-hetzner-vault-runtime.md — “converging toward” → “converged” (Phase 1 completata).

Added to index:

• entities/hashicorp-vault.md — mancante dalla sezione Entities.

Why it matters: the wiki now riflette l’architettura corrente (ExternalName egress proxy, CoreDNS Disable&Replace) invece del relay DaemonSet obsoleto, e documenta lo stato Phase 2 appena sbloccato.

[2026-05-28] update | Bootstrap engine restructured — CoreDNS user-managed, Vault-native secrets, one-shot cluster

Updated 2 wiki pages to reflect the bootstrap restructuring (2026-05-28):

Updated:

• entities/ephemeral-castle.md — Updated repo structure description (engine layer now includes CoreDNS + vault secrets + direct file tokens), added TD-028/029/030 to Known Issues.
• topics/ephemeral-castle-rebirth-protocol.md — Full rewrite of the bootstrap flow: Talos patches baked into proxmox-talos module, engine layer details (CoreDNS, vault secrets, github/tailscale tokens), bootstrap deadlock avoidance table, PGO sync step, final convergence timing.

Key content added:

• CRITICAL LESSON documented: machine.certSANs ≠ cluster.apiServer.certSANs. Wrong path triggers trustd PKI regeneration causing cluster deadlock.
• Bootstrap deadlock table with 6 fix scenarios.
• Bootstrap order: platform → engine (CoreDNS+vault+secrets) → networking+gitops → storage → PGO sync → Grafana.

Why it matters: The wiki now describes the actual one-shot bootstrap process that requires zero manual intervention, replacing the old process that had circular dependencies and manual secret creation steps.

[2026-05-28] update | Tailscale DNS container fixes — stateful filtering, auto-start, update-hosts

Updated 3 wiki pages to reflect the Tailscale DNS fixes in the TazPod container (2026-05-27→2026-05-28):

Root cause documented: Tailscale v1.66+ stateful filtering drops UDP DNS from Docker bridge interfaces to MagicDNS (100.100.100.100). Fix: --stateful-filtering=false, --accept-dns=false, update-hosts.sh.

Updated:

• references/tailscale/start-sh.md — Full rewrite aligned with actual start.sh: stale process cleanup, --stateful-filtering=false, --accept-dns=false, update-hosts.sh call. Added changelog table.
• topics/tailscale-operator-connectivity.md — Removed “no auto-start mechanism” statement. Added DNS root cause section, auto-start via .bashrc, update-hosts.sh reference. Updated TUN mode section with all DNS flags.
• details/tazpod-dotfiles-detail.md — Corrected Tailscale Auto-Start section with actual if/else logic: first shell launches start.sh, second shells run update-hosts.sh. Added DNS fix chain note.

Why it matters: The wiki now correctly documents the current Tailscale DNS architecture inside the TazPod container instead of the outdated userspace-only, no-auto-start state. Operators and agents can understand the stateful filtering root cause, the fix chain, and the auto-start behavior from the wiki without reading the scripts.

[2026-05-22] update | wiki Vault migration completata — Infisical come legacy

Updated 3 pages to reflect completion of Vault migration and Infisical retirement:

Updated:

• wiki/topics/tazlab-k8s-secrets-mapping.md — riscritta: tabella con Vault paths reali, two-store model (Vault primary, Infisical legacy). Rimossa sezione bootstrap Infisical.
• wiki/entities/infisical.md — riscritta: da “current backend” a “superseded by Vault, legacy fallback”. Aggiunta sezione decommission timeline.
• wiki/details/tazlab-k8s-external-secrets-detail.md — aggiornata: tabella with two stores (Vault primary, Infisical legacy).
• wiki/entities/hashicorp-vault.md — consumer migration → Completed.

Why it matters: future agents reading the wiki will now see Vault as the primary backend, not Infisical.

[2026-05-24] lint | Infisical/Zero-SOPS stale references pulite su 23 pagine

Trigger: Allineamento wiki a codice dopo sessione CRISP project 15 e ricerca Vault Agent Injector.

Contesto: 23 pagine wiki ancora citavano Infisical come backend attivo. Ricerche agent sui repo live hanno confermato:

• env.hcl non ha piú variabili Infisical (ora usa get_env() da ~/secrets/)
• secrets-fetcher module non usa Infisical (legge solo env vars)
• Terragrunt layers non creano piú provider Infisical
• ClusterSecretStore tazlab-secrets ha credenziali vuote — nessun ExternalSecret lo referenzia
• SOPS/age non sono mai stati in uso nel codice attuale

Pagine corrette (lista completa in appendix):

Why it matters: Future agent che legge wiki vede Vault come backend attivo. Informazioni allineate al codice live.

Pages Updated

• entities/hashicorp-vault.md — CRISP status 10/12 Completed, 22 ExternalSecrets, Tailscale Operator exposure completata, Vault Agent Injector future
• entities/tazlab-k8s.md — backend da “Infisical (→ Vault)” a “Vault”
• entities/ephemeral-castle.md — layer 1 da “Infisical” a “bootstrap credentials (~/secrets/)”
• entities/infisical.md — da “superseded in progress” a “decommissioned”
• topics/tazlab-secret-and-identity-flow.md — riscritta: layered model Level 1/2/3, Vault backend, Infisical legacy, future Agent Injector
• topics/tazlab-k8s-bootstrap-logic.md — Infisical → Vault
• topics/tazlab-k8s-ingress-and-auth.md — Infisical → Vault per wildcard TLS
• topics/tazlab-k8s-operators-inventory.md — ClusterSecretStore e Tailscale OAuth source da Infisical a Vault
• topics/tazlab-k8s-configs.md — “Infisical-backed” → “Vault via ExternalSecret”
• topics/ephemeral-castle-architecture.md — Infisical → env vars da ~/secrets/
• topics/ephemeral-castle-repository-map.md — Infisical-backed → bootstrap ~/secrets/
• topics/ephemeral-castle-proxmox-talos-foundation.md — Infisical → ~/secrets/
• topics/ephemeral-castle-cluster-bootstrap.md — Infisical → operator env vars
• topics/tazlab-infrastructure-tech-stack.md — Infisical → Vault
• details/tazlab-k8s-external-secrets-detail.md — tabelle “Infisical Key” → “Vault Path”. Aggiunte voci: Tailscale, Grafana, AWS backrest. Aggiunto future Agent Injector.
• details/tazlab-k8s-cert-manager-detail.md — Infisical → Vault path
• details/tazlab-k8s-dex-oauth2-detail.md — Infisical → Vault
• details/tazlab-k8s-hugo-wiki-detail.md — Infisical → Vault
• details/tazlab-k8s-openclaw-detail.md — Infisical → Vault
• details/ephemeral-castle-terragrunt-layers-detail.md — Infisical → operator env vars, ClusterSecretStore → Vault
• details/ephemeral-castle-terraform-modules-detail.md — Infisical → operator environment
• references/ephemeral-castle/env-hcl.md — riscritta: no Infisical vars, get_env() source table
• references/tazlab-k8s/external-secret-example.md — name da tazlab-secrets a tazlab-secrets-vault
• homepage.md — “Infisical transizionale” → “Vault primario”

[2026-05-27] update | Tailscale service exposure + bashrc auto-start

What changed

• Created wiki/topics/tailscale-service-exposure.md — 6 services migration from MetalLB/Traefik to Tailscale Ingress/LoadBalancer
• Updated wiki/references/tazpod/bashrc-full.md — added tailscale auto-start block with setsid
• Updated wiki/index.md — added tailscale-service-exposure to Tailscale Networking section

Why it matters

Service exposure via Tailscale is now the canonical path for internal services. Documentation was missing the migration details, design decisions (D1-D4), and the correct tailscale startup configuration.

[2026-05-27] review | Full wiki alignment (tailscale area)

What changed

• Updated wiki/entities/tailscale.md — OAuth scopes updated (services+auth_keys), TD-020 closed, DNSConfig CR story corrected, Service Exposure link added
• Updated wiki/details/tailscale-oauth-client-detail.md — added k8s_operator client with services scope, credential storage for both clients, key minting via tazpod-tailscale-up
• Updated wiki/details/tailscale-acl-policy-detail.md — added tag:k8s, tag:internal-apps, new ACL rules for service exposure, fixed “planned” labels to active
• Updated wiki/topics/tailscale-iac-management.md — added k8s_operator OAuth client definition with services scope

Pages OK

• entities/tailscale.md — now reflects current state (TD-020 closed, OAuth scopes, exposure)
• details/tailscale-oauth-client-detail.md — both clients documented, correct scopes
• details/tailscale-acl-policy-detail.md — all tags and rules current
• topics/tailscale-iac-management.md — k8s_operator added
• topics/tailscale-service-exposure.md — newly created (this batch)

Pages with stale info (fixed)

• entities/tailscale.md: OAuth scope “devices” → “devices, auth_keys, services”
• entities/tailscale.md: TD-020 open → closed (replaced with TD-025)
• details/tailscale-acl-policy-detail.md: missing tag:k8s-operator, tag:k8s, tag:internal-apps
• details/tailscale-acl-policy-detail.md: “planned” labels on active rules
• topics/tailscale-iac-management.md: missing k8s_operator client

Cross-area findings

• wiki/docs/ directory missing archivist-procedure.md (referenced by AGENTS.ctx/wiki/CONTEXT.md but file lives in AGENTS.ctx/wiki/docs/)

[2026-05-27] update | Tailscale TUN fix + .bashrc auto-start

• references/tailscale/start-sh.md: updated daemon start with TUN auto-detect (kernel-native when /dev/net/tun available, userspace fallback otherwise)
• references/tazpod/bashrc-full.md: replaced old blocking tazpod-tailscale-up call with non-blocking tools/tailscale/start.sh via setsid, singleton socket check, visible rocket message
• details/tazpod-dotfiles-detail.md: added Tailscale Auto-Start section with code block and timing notes
• entities/tazpod.md: bumped current version from 0.3.30 → 0.3.35
• entities/tailscale.md: updated operator daemon description to reference tools/tailscale/start.sh with TUN detection

[2026-05-29] update | ProxyGroup kube-apiserver + Vault DB engine

Updated:

• entities/hashicorp-vault.md — added Database Engine, JWT auth, ProxyGroup, VM route acceptance, container details
• topics/tailscale-service-exposure.md — added ProxyGroup section, VIP routing note, –accept-routes requirement

Context: Replaced LoadBalancer Service with ProxyGroup for K8s API server exposure. Enabled Vault Database Secret Engine for PostgreSQL dynamic credentials. Configured Vault JWT auth with jwks_url. SSH key injected via Hetzner rescue mode. All 5 Mnemosyne memories saved.

[2026-05-29] update | Cross-check CRISP plan vs wiki — fixes applied

Cross-checked the CRISP plan for 10-vault-agent-injector-phase1 against the wiki. Found and fixed:

• Cilium assumption removed (cluster uses Flannel, confirmed by wiki)
• CoreDNS IP corrected from old relay 10.96.0.101 to current DNSConfig architecture
• Flux DAG dependsOn corrected to infrastructure-tailscale-dns (DNS readiness before injector)
• PLAN Stages 1-3 marked as completed (work done in session)
• Wiki entities updated: tazlab-k8s.md (K8s version, CNI), ephemeral-castle.md (K8s version, CNI, oidc-reviewer, JWKS endpoint)

[2026-05-29] update | Stage 4-5 completed — Vault Agent Injector + Grafana migration

Updated:

• entities/hashicorp-vault.md — add Vault Agent Injector status, Grafana migration, known bugs
• topics/tailscale-service-exposure.md — already updated in earlier session

Key events:

• Vault Agent Injector deployed (chart 0.32.0, injector-only, JWT auth via ProxyGroup)
• vault-k8s bug #660 workaround (auth-config-path annotation)
• Grafana migrated to dynamic Vault credentials (GF_DATABASE_USER__FILE / __PASSWORD)
• ExternalSecret tazlab-db-pguser-grafana removed
• Sidecar disabled via agent-pre-populate-only (read-only FS on Talos)
• All credentials verified working

[2026-05-29] update | Vault Agent Injector Pattern documentation + Followup completion

Created:

• topics/vault-agent-injector-pattern.md — standard annotation set, Talos-specific requirements, bug #660 workaround, troubleshooting

Updated:

• entities/hashicorp-vault.md — add Injector Pattern reference

Context: Completion of 11-vault-agent-injector-phase1-followup project.

[2026-06-01] update | Vault JWT auth fix, monitoring sbloccato, vault-k8s-config Ansible playbook

What changed

• Vault JWT bound_issuer corretto: Aggiornato da singolo issuer a concatenazione multi-issuer richiesta da Talos: "https://lushycorp-k8s.magellanic-gondola.ts.net:6443,https://kubernetes.default.svc.cluster.local"
• Vault database engine: Password tazlab-admin aggiornata dopo destroy+create (PGO genera nuova password)
• grafana-sa ServiceAccount: Creata e aggiunta come manifest Flux in tazlab-k8s/infrastructure/operators/monitoring/grafana-sa.yaml
• Monitoring stack: kube-prometheus-stack v61.3.1 installato e funzionante (Grafana 3/3, Prometheus 2/2, kube-state-metrics, node-exporter)
• Vault K8s config migrata in Ansible: Creato playbook vault-k8s-config.yml (stage k8s_config) che configura JWT auth + database engine via kubectl exec sul pod vault-configurator. Sostituisce shell inline in create.sh
• TD-034: Aggiornato a “In progress” con nota sulla risoluzione parziale

Pages created

• ephemeral-castle/runtimes/lushycorp-vault/hetzner/ansible/vault-k8s-config.yml
• ephemeral-castle/runtimes/.../roles/vault-runtime/tasks/k8s-config.yml
• tazlab-k8s/infrastructure/operators/monitoring/grafana-sa.yaml

Why it matters:

Il cluster è pienamente operativo dopo destroy+create con monitoring attivo. Config Vault in Ansible idempotente. grafana-sa gestita da Flux. Prossimo destroy+create applica tutto automaticamente.

[2026-06-01] update | One Shot Cluster raggiunto — 14m 15s full ciclo

What changed

• One Shot Cluster: Quarto ciclo destroy+create (full da zero) completato in 14m 15s senza interventi manuali.
• Fix finali: VAULT_ANSIBLE_DIR usa SCRIPT_DIR, Ansible retry loop (until/retries=30/delay=10) su database config per gestire finestra password PGO post-restore.
• Stato: Flux 19/19, VSO 10/10, Grafana 3/3, DB 4/4.

Pages updated

• ephemeral-castle/clusters/tazlab-k8s/proxmox/create.sh — path fix + PGO wait migliorato
• ephemeral-castle/.../roles/vault-runtime/tasks/k8s-config.yml — retry loop su database config

Why it matters:

Cluster completamente automatizzato. Prossimi cicli destroy+create non richiedono interventi.

[2026-06-05] forge | ephemeral-castle context

What changed

Created a pre-built operational context for the full ephemeral-castle infrastructure layer.

Pages created

• wiki/contexts/ephemeral-castle-context.md — Full context: scope, wiki reading list, memory/debts/CRISP references, repo structure, execution hints, known pitfalls, open questions

Pages updated

• wiki/contexts/INDEX.md — Added ephemeral-castle entry to context library index

Why it matters:

Provides a self-contained working brief for any agent working on the infrastructure layer (Proxmox, Talos, Terragrunt, Vault runtime, Tailscale, Hermes) without requiring preliminary research across wiki, memory, and CRISP.

[2026-06-07] cycle | 9th destroy+create — terragrunt cache fix, one-shot terragrunt phase

What changed

5th destroy+create cycle after Ansible→Terraform migration. Terragrunt part now fully one-shot (secrets → vault-jwt → engine → platform → parallel layers). Flux convergence needs manual post-steps for database + monitoring.

Bugs fixed

• Terragrunt -reconfigure mancante → engine falliva dopo cache cleanup
• Namespace engine mancanti (tailscale, external-secrets, tazlab-db)
• Dex namespace in operator wrong dir (VSO bloccato)
• Create.sh exit code mascherato da echo "EXIT_...:$?"
• Core kustomization riferiva operator dir eliminate (dex, tazlab-db)

Still manual (post-Flux)

• Privilege enforcement (ALTER ROLE) per DB password sync
• vault-db-config apply con password aggiornata
• VSO VaultDynamicSecret reconcile forzato

Why it matters

Terraform/Terragrunt phase ora one-shot anche dopo cache cleanup. 9 interventi manuali → 2 interventi manuali.

[2026-06-07] milestone | First true one-shot destroy+create (9th cycle)

What happened

Ansible->Terraform migration completed. Cycle 9 achieved first one-shot cluster bootstrap: create.sh exit code 0, zero manual interventions, 83 pods in 8m30s.

Key discoveries

• Post-Flux is redundant: vault-db-config applied before platform (persistent Vault layer), passwords sourced from secrets-fetcher (same root for engine and vault-db), VSO auto-reconciles VaultDynamicSecret. No ALTER ROLE, no VDS annotation, no smoke test needed.
• VSO reconciliation: VSO reconciles grafana-dynamic-creds within minutes without any annotation trigger. With vault-db-config applied before VSO starts, the refresh is fast enough.
• kubectl wait pod master: kubectl wait for=condition=Ready pod -l role=master fails IMMEDIATELY if no pod matches the label. Must poll for pod existence first.
• Terragrunt cache cleanup: extra_arguments init_reconfigure + disable_dependency_optimization = true required to survive cache cleanup.

Result

Total time: 8m30s. All 21 Flux kustomizations, Blog, Wiki, Grafana, Prometheus, DB, Mnemosyne, pgAdmin fully operational.

[2026-07-05] restructure | PKI Vault project wiki sweep

Updated the wiki to reflect PKI Vault project changes (2026-07-01 to 2026-07-03):

• VSO active as primary secret delivery operator, ESO dormant, Vault Agent Injector removed
• Infisical fully decommissioned, all entity pages updated to decommissioned status
• cert-manager ClusterIssuer renamed from tazlab-issuer to letsencrypt-issuer
• Blog and wiki now use Let’s Encrypt cert-manager Certificates (blog-tazlab.net-tls with 4 domains, wiki-tazlab.net-tls)
• Internal ingress TLS uses Vault PKI (*.tazlab.net) via VSO VaultPKISecret (vault-pki-tls)
• Database mTLS documented: customTLSSecret + customReplicationTLSSecret + pg_hba cert auth for Grafana
• Grafana mTLS documented: VaultPKISecret, extraInitContainers, ssl_mode/GODEBUG=tlskyber=0
• PKI 3-tier architecture (Offline Root GPG → Intermediate → Generated) documented on Vault runtime pages
• 8 PKI roles + 8 JWT policies for per-namespace auth documented
• VSO Flux DAG added (infrastructure-operators-vso → infrastructure-vso-secrets → infrastructure-tls)
• Vault Agent Injector pattern page marked as historical
• Known issues updated: TD-041, TD-042, TD-043 added where applicable
• Vault runtime architecture page expanded with PKI secret engines section
• Zero-trust architecture updated: Infisical → Tailscale OAuth
• Overview.md refreshed with current coverage
• All pages: stale Infisical, ESO-primary, VAI, wildcard-tls references corrected

Updated:

• Entities: hashicorp-vault, tazlab-k8s, ephemeral-castle, infisical
• Topics: secret-flow, ingress-auth, secrets-mapping, operators-inventory, operators, flux-dag, bootstrap-secrets, configs, conventions, structure, repo-mapping, layers, monitoring, system-map, VAI-pattern, tailscale-exposure, tailscale-vault-contract, vault-runtime-architecture, vault-bootstrap-restore
• Details: cert-manager, external-secrets, monitoring, tazlab-db, dex-oauth2, mnemosyne-deployment, terraform-modules, create-destroy, ansible-scripts, systemd, magicdns
• Other: zero-trust-architecture, lushycorp-vault-context, overview, homepage, index

Why it matters:

The wiki now correctly reflects the post-PKI project state: VSO-based secret delivery, Let’s Encrypt + Vault PKI TLS, database mTLS, and Infisical fully retired. This prevents agents from learning outdated secret-flow or TLS architecture from the wiki.

[2026-07-05] fix | VaultPKISecret template bug discovered and fixed

During a routine deploy test, discovered that VaultPKISecret transformation.templates with excludeRaw:true was missing tls.crt and tls.key mappings — only ca.crt was templated. This caused VSO to produce invalid kubernetes.io/tls secrets on certificate renewal (missing required tls.crt/tls.key fields). Fixed by adding tls.crt and tls.key templates to all 6 VaultPKISecrets. See chronicle 2026-07-05 for details.

[2026-07-11] update | PKI/mTLS alignment

Updated wiki pages after PKI and mTLS project completions:

• entities/hashicorp-vault.md: Vault Database Engine marked as removed, CRISP projects updated with PKI entries, mTLS status added.
• topics/tazlab-secret-and-identity-flow.md: Updated to reflect VSO as primary, ESO dormant, gopass migration in progress.
• topics/tazlab-k8s-secrets-mapping.md: Added VaultPKISecret table with 6 client/server certs, updated VSO section, noted Grafana DB password no longer used.
• details/tazlab-k8s-tazlab-db-detail.md: Expanded mTLS section to cover all 3 apps (Grafana, mnemosyne, pgAdmin), added pg_hba rules, Vault DB engine removal.
• details/tazlab-k8s-monitoring-detail.md: Fixed Grafana ssl_mode from disable to require, added note about grafana-dynamic-creds removal.=== wiki/log.md append ===

2026-07-14: Wiki update for gopass migration

• Updated: entities/tazpod.md (gopass architecture), topics/tazpod-architecture.md (simplified), topics/tazpod-vault-security.md (deprecated), topics/tazpod-nomadic-workflow.md (simplified), topics/tazlab-secret-and-identity-flow.md (gopass), operations/tazpod-cli-reference.md (deprecated vault commands)
• Created: topics/tazpod-gopass-migration.md (new)
• Deprecated: details/tazpod-vault-lifecycle-detail.md, details/tazpod-sync-daemon-detail.md, details/tazpod-crypto-detail.md, details/tazpod-s3-detail.md, topics/tazpod-sync-daemon.md
• Updated: entities/hashicorp-vault.md (Infisical refs), entities/infisical.md (historical banner)
• Updated: wiki/index.md (added Gopass Migration section)

[2026-08-12] update | Hermes Agent redesign — LXC → KVM VM 501

Hermes Agent migrated from LXC container (CT 105, Debian 12) to a dedicated KVM VM (VM 501 hermes, Ubuntu 26.04, 4 vCPU/8 GB) in a standalone repo github.com/tazzo/hermes-agent. CRISP project hermes-agent-redesign completed (report: skills/memory/reports/2026-08-12_hermes-agent-vm-redesign.md).

Updated pages:

• entities/hermes.md — Full rewrite: VM 501 KVM architecture, standalone repo, lvrename orphan persistence pattern, dashboard auth (basic auth + scrypt), gopass secret paths, key discoveries from destructive tests.
• topics/hermes-vm-deployment.md — NEW: current KVM deployment architecture (replaces LXC page).
• topics/hermes-lxc-deployment.md — Marked SUPERSEDED (CT 105 destroyed), kept for historical reference.
• entities/ephemeral-castle.md — Removed hermes/ directory from structure, updated relationship (moved out to standalone repo).
• contexts/ephemeral-castle-context.md — Removed Hermes LXC references, updated CRISP registry row (project renamed to hermes-agent-vm-redesign, completed).
• contexts/INDEX.md — Updated ephemeral-castle context entry.
• wiki/index.md — Updated hermes entity description + added new topic under AI Agent Services section.

[2026-08-30] update | Hindsight platform documented + memory migration status

Documented the new Hindsight multi-agent memory platform (Vectorize.io, deployed 2026-08-28) and the in-progress legacy memory migration from Mnemosyne, following the 4-level model.

Created:

• entities/hindsight.md (Level 1 hub — quick facts, manifest tree, starting pages, relationships)
• topics/hindsight-architecture.md (Level 2 — 3-pod stateless design, zero-PVC rationale, bank model, LLM/embedding quota pacing, migration protocols mark-before-advance + done=searchable, deep-verification findings)
• details/hindsight-deployment-detail.md (Level 3 — file-by-file manifest map, API env contract, 4 documented gotchas, PGO database chain, VSO secret/PKI recipe, digest pinning, NetworkPolicy)

Updated:

• entities/mnemosyne-mcp-server.md — coexistence section (read-only legacy layer until migration sign-off)
• concepts/tazlab-knowledge-layers.md — added the Hindsight layer, mnemosyne marked read-only during migration
• index.md — hindsight entity/topic/detail entries added

Why it matters: Hindsight becomes TazLab’s shared searchable memory for all agents; the wiki now records its architecture, the exact deployment contract (env collision, control-plane port, pgvector superuser requirement, fsGroup), the bank design ratified by the memory-migration-hindsight project, and the live migration state (137 items imported, 2026-01 batch in progress) so future agents do not rediscover the year-hallucination audit or re-hit the embedding quota wall blind.

[2026-09-10] review | two-month alignment sweep (2026-07-10 → 2026-09-10)

What changed

Full review of the wiki against memory (chronicle + past-summary + debts) and live repositories, covering the last two months of TazLab activity. Four clusters of changes:

1. Skills migration (2026-07-29) — 9 AGENTS.ctx-era pages reframed to the OMP skills system: entities/agents-ctx.md (now describes the /workspace/AGENTS.md loader + SKILLS/ with the 10-skill registry and legacy not-migrated areas), context-system, memory-system, crisp-methodology, pi-council + wiki-archivist (marked legacy/not migrated), archive-flow / crisp-workflow / memory-files details; cross-references fixed in homepage, overview, knowledge-layers, system-map, repository-map, operating-model, wiki-tazlab-net, mnemosyne-mcp-server, contexts/INDEX, blog-post-workflow-detail, mnemosyne-mcp-debts-detail, crisp-program-map, secret-and-identity-flow, terragrunt-layers, lxc-storage-crisp-design, tazpod-dotfiles-detail, bashrc-full.
2. tazlab-k8s cluster area — ESO→VSO dex/oauth2 migration (3 VaultStaticSecrets, static dex ConfigMap, zero ExternalSecrets left, ESO truly dormant), homepage app topic page NEW (2026-08 outage: unpinned homepage:latest → v2.0.0 auth gate rejected kubelet probe Host; fixes: pin v2.1.2, probe Host header, image automation, cloudflare-ddns pin 1.17.0), Alertmanager no-receivers state (TD-057, correct key alertmanagerSpec.configSecret, reverted fix b0b46bc), 21 Flux kustomizations, homepage image-automation pipeline #4 (ghcr + semver), repo made public 2026-07-16 after git-filter-repo history purge. Pages: entities/tazlab-k8s, monitoring topic + detail, dex-oauth2-detail, external-secrets-detail, secrets-mapping, image-automation topic + detail, flux-dag, operators-inventory, flux-kustomizations-detail, NEW topics/tazlab-k8s-homepage.
3. Hermes — entities/hermes.md + hermes-vm-deployment.md extended with the five post-2026-08-12 additions: hermes-restart.service (CLI restart not bypassable — hardcoded root guard), Caddy research publisher (:8080, VPN-only, linger), hermes-chrome.service (durable headless Chrome, CDP 127.0.0.1:9222, connect_over_cdp only), Samba CIFS mount from CT 107 (gopass-sourced creds, automount), VM-side refurb collector (T14/L14/X13 Gen 2 filter, cron 2 days).
4. Hindsight section — NEW topics/hindsight-migration-status.md (Level 2): live import state 754 docs done (per-batch table from import-state.json), backlog (3 new-sep + 19 chronicle archives + 57 reports + 69 doctrine docs), TD-058 date-marker corruption closed permanently 2026-09-03 (sanitize_content() guard, re-retain 23/224, resume via td058_restrain.py, ~22% null occurred_start as residual limitation), remaining known issues. entities/hindsight.md + hindsight-architecture.md updated to the half-migrated framing.

Why it matters

The wiki was last aligned on 2026-08-30 (Hindsight) and described a pre-migration context system, an ESO-era cluster, a homepage with no incident history, a Hermes VM without its post-August services, and no record of the tazlab-k8s public/history-purge event. Agents navigating the wiki would have learned obsolete secret delivery, obsolete skill-loading paths, and a stale migration state.

[2026-09-10] update | CT106 runtime + dsh Web UI documented; nginx reverse proxy retired

Added:

• details/tazpod-proxmox-runtime-detail.md (Level 3 — CT106 tazpod-proxmox provisioning via tazpod/runtimes/lxc with the full create.sh phase list, Ansible layer inventory, the idempotency rules learned on 2026-09-10, the dsh Web UI service contract, the SSH-loopback access model with token/cookie lifecycle, and the legacy nginx + sync-daemon removal)

Updated:

• entities/tazpod.md — new “LXC Runtime (CT106)” section linking the runtime detail
• index.md — details entry for the CT106 runtime page

Why it matters: CT106 hosts the DeepSeek Harness Web UI, and until now the wiki had no page for that container at all. The detail records why dsh must stay bound to 127.0.0.1:3081 (privileged RPCs are pinned to the loopback origin: any reverse proxy returns HTTP 403 and silently degrades settings persistence), how remote access is meant to work (SSH port forward + one-time launch token → 30-day cookie), and the two leftovers that were removed the same day (nginx on :3080 and the restart-looping tazpod-sync.service with 10,117 restarts). It also captures the IaC traps that broke create.sh and the playbook for months — missing heredoc terminator, /workspace/... controller paths, authorized_key moved out of ansible-core, herdr vs hdr, and the .ssh directory→symlink refusal — so a future agent does not rediscover them, plus the cordis.patch.yml must-be-an-array gotcha that aborts dsh at boot.

[2026-09-10] update | Hindsight ingest fix + Flux DAG freeze root cause and hardening

Updated:

• details/hindsight-deployment-detail.md — fifth documented gotcha: OpenCode Go requires a stable x-opencode-session per conversation (HTTP 400 MissingSessionID otherwise) and Hindsight’s ingest reports nothing to the caller, so every ingest of the migration window was silently lost; fix is HINDSIGHT_API_LLM_DEFAULT_HEADERS on api + worker, with the shared-prompt-cache trade-off recorded
• details/tazlab-k8s-flux-kustomizations-detail.md — new “DAG Freeze: Root Cause and Hardening” section: 13/23 Kustomizations stuck in DependencyNotReady with nothing actually failing, single root object, missed dependency-ready requeue; hardening = 15-minute intervals plus the flux-dag-watchdog CronJob (2-minute schedule, 3 passes, dedicated least-privilege RBAC, hardened container) verified by recovering a frozen DAG to 23/23

Why it matters: both failures were invisible. The Hindsight one silently discarded every memory ingested during the migration (the caller saw queued), and the Flux one left the platform half-applied for ~16 hours after a reboot while every dashboard stayed “green” because nothing was failing. Recording the mechanisms, the supported configuration knob and the residual alerting gap (TD-067, TD-057) means the next agent diagnoses both in minutes instead of re-deriving them — and knows that a frozen DAG is a Flux re-queue behaviour, not a broken workload.

[2026-09-14] update | dsh/CT106 nginx-era residue removed (TD-069 + TD-065 closed)

Updated:

• details/tazpod-proxmox-runtime-detail.md — legacy section rewritten: /etc/dsh-tls/ key material deleted from CT106, the LAN isLoopback vendor patch reverted by reinstalling the clean dsh package (verified in the source tree AND in the bundle actually served to the browser), patch-remote-settings.sh deleted, web-login-url.sh rewritten to print the loopback tunnel URL, and the now-unused infra/dsh-tls/* secrets removed from the store

Why it matters: the loopback origin is what authorises dsh’s privileged RPCs, so a leftover LAN-IP patch is not cosmetic — it re-opens the exact bypass the SSH-tunnel design exists to close, and the helper scripts would have re-applied it or pointed operators at a dead login URL. The residue is now gone on this host, the detection method (grep the install tree and the served bundle) is recorded, and the last nginx TLS private key no longer lives on a machine that stopped needing it.

[2026-09-21] update | Pi package rename + retired root-context references removed

What changed

• references/tazpod/dockerfile-ai.md + topics/tazpod-image-hierarchy.md — Pi coding agent package updated from the deprecated @mariozechner/pi-coding-agent to @earendil-works/pi-coding-agent, with a migration note (the old package’s last release is 0.73.1 and prints “please use @earendil-works/pi-coding-agent instead going forward”; the live CT106 container was already migrated by pi update).
• Removed dead references to the retired root context tree across the wiki: every path that resolved under it (tailscale scripts, memory files, CRISP projects, per-area CONTEXT.md files) was repointed to the live SKILLS/... path or dropped. Pages touched: entities/agents-ctx.md, entities/infisical.md, entities/wiki-tazlab-net.md, entities/hermes.md, index.md, overview.md, concepts/tazlab-knowledge-layers.md, contexts/INDEX.md, docs/tazlab-integration.md, README.md, and the topics/details/operations pages for ephemeral-castle, tailscale, tazpod, tazlab-cluster-delivery-flow, tazlab-flux-dag, tazlab-crisp-program-map, tazlab-k8s-bootstrap-secrets, tazlab-repository-map, tazlab-secret-and-identity-flow, tazlab-system-map, mnemosyne-mcp-debts, blog-post-workflow, blog-content-structure, hermes-lxc-deployment, agents-ctx-*.
• references/tazpod/bashrc-full.md — the quoted .bashrc tailscale block synced to the live file, which already uses /workspace/SKILLS/tools/tailscale/.
• index.md — the explicitly-retired pages (pi-council, wiki-archivist) moved under a labelled “Legacy, retired” grouping; contexts/ marked a legacy static catalog.
• log.md — banner added at the top noting that pre-2026-07-29 entries reference the retired tree (append-only history kept verbatim).

Why it matters

The retired root context tree no longer exists on disk, so every one of those paths was a dead link pointing agents at files that are not there. The Pi reference documented a deprecated package, so any rebuild from the wiki’s own guidance would have pinned the frozen 0.73.1 release. The wiki now points only at live SKILLS/... paths and records the rename, so a reader following any path lands on a real file.

[2026-09-24] update | teaching.tazlab.net documented; stale site TLS/ExternalSecret claims corrected

What changed

Documented the new didactics surface at teaching.tazlab.net (CRISP project teaching-tazlab-net), and corrected two site detail pages that still described the retired ExternalSecret era.

Created:

• details/tazlab-k8s-teaching-detail.md (Level 3) — namespace teaching and the manifest map; the Deployment/Service contract (port 8080, non-root 10001, read-only rootfs + /tmp emptyDir, startup/readiness/liveness probes, 200m/256Mi → 2/512Mi); the environment contract including the optional: true OPENCODE_API_KEY; exposure (Traefik main Ingress + Certificate teaching-tazlab.net-tls via ClusterIssuer letsencrypt-issuer, plus the separate web-only redirect Ingress and why a redirect middleware on the sites’ HTTPS-only router would be a no-op, with the ACME solver-priority reasoning); the Vault-delivered OPENCODE_API_KEY (VaultStaticSecret + vaultauth allowedNamespaces requirement, failure mode); the runtime contract (uvicorn flags, proxy-headers trust, graceful shutdown, build stages); the logging contract (JSON lines, request_id, WARN on discarded items and degraded LLM, no secrets); image automation; the full delivery chain; DAG position; deviations from the site lane.

Updated:

• details/tazlab-k8s-hugo-wiki-detail.md — the TLS row and the matching sentence no longer claim “wildcard-tls via ExternalSecret from Vault tazlab-secrets-vault”: the wiki has its own cert-manager Certificate (wiki-tazlab.net-tls, letsencrypt-issuer, HTTP-01, Ready=True live), the repository holds zero ExternalSecrets, and the Vault-PKI wildcard is not used there. The DAG block now reads “creates ClusterIssuer letsencrypt-issuer — no ExternalSecrets exist”, and the manifest table lists certificate.yaml + kustomization.yaml so the TLS claim is checkable from the page itself.
• details/tazlab-k8s-hugo-blog-detail.md — the DAG block no longer claims configs “creates github-external-secret for Flux automation”; it now states the ClusterIssuer and that Flux commits with the flux-system GitRepository credentials.
• index.md — catalogue row for the new detail page under Details.

Why it matters

teaching.tazlab.net is a new public surface, and the first publicly exposed site whose runtime differs from the nginx pattern (Python service with probes and resource limits, read-only rootfs, and a Vault-delivered key of its own), so the exact contract — including the two silent failure modes, optional: true hiding a rejected VaultStaticSecret and a redirect middleware that cannot fire on an HTTPS-only router — now lives in the wiki instead of only in the CRISP project. The two corrected pages had been asserting removed mechanisms (ExternalSecret-delivered wildcard TLS, github-external-secret): verified live, there are zero ExternalSecret resources cluster-wide and both sites use cert-manager Certificate objects, so anyone following those pages would have gone looking for a resource that no longer exists.

[2026-09-25] decommission | dsh Web UI removed from CT106 and from the Ansible baseline

The DeepSeek Harness (dsh) Web UI was retired because it is no longer used. The removal touched three layers and is recorded here because the durability rules for this container (rebuild from Ansible, idempotent convergence) make it easy to resurrect a removed surface by accident.

Changed:

• details/tazpod-proxmox-runtime-detail.md — the dsh Web UI and SSH-loopback access sections are gone, replaced by a “Removed” section listing what was deleted; the page also records the re-run assessment of the Ansible baseline (--check: ok=71 changed=2 failed=0) and the live container resources.
• index.md and entities/tazpod.md — catalogue and link descriptions no longer advertise a dsh access model.
• tazpod repository (runtimes/lxc): deleted ansible/roles/tazpod/tasks/layer5-dsh.yml and templates/dsh.service.j2, removed the restart dsh handler, the dsh_version/dsh_web_port defaults, the layer import, the dsh checks in create.sh and the dsh rationale in terraform.tfvars.
• SKILLS/tools/dsh-web-access/ (tunnel helper, TOOL.md, research note) and its row in SKILLS/tools/SKILL.md.

On the container: the dsh.service unit was stopped, disabled and deleted (daemon-reload), the @deepseek-ai/dsh package was removed from the tazpod user’s nvm prefix (520 packages), and /var/log/dsh-web.log was deleted. ~/.dsh/ (41 MB of profiles, settings, sessions) was deliberately left in place — it holds operator settings and history, so its deletion is a separate, explicit decision.

Why it matters:

A container that is rebuilt from Ansible converges to whatever the role says, so a removed service that still exists in the role — or a service still enabled on the live container — would come back on the next cycle. Removing it in both places is what makes the decommission durable; the replacement operator surface (Paperclip, CRISP project paperclip-lxc-deployment) is being designed to live on the same container, so the wiki must not keep describing the old one as the access path.

Correction (2026-09-25, same day). The entry above initially stated that ~/.dsh/ had been left in place. It was subsequently deleted on explicit operator instruction; details/tazpod-proxmox-runtime-detail.md and the CRISP project’s RESEARCH.md were corrected to record the deletion, which was also verified live (no ~/.dsh under /home/tazpod or /root, no dsh package in the nvm prefix, nothing listening on 3081).

[2026-09-25] service | Paperclip deployed on the TazPod container

CRISP project paperclip-lxc-deployment built and verified: Paperclip (npm paperclipai, agent control plane) now runs natively inside CT106 as paperclip.service, reachable on the private network at http://192.168.1.206:3100 in authenticated + private mode.

Created:

• details/paperclip-tazpod-detail.md — the service page: provisioning layer, database identity, secrets channel, unit hardening notes and operations
• index.md, entities/tazpod.md — links to the new page

Why it matters:

The container gained its operator surface after the dsh decommission, and the durable part is the provisioning, not the running process: the service is recreated from the TazPod Ansible baseline (layer5-paperclip), its state lives on the pet volume so a rebuild does not rotate the secrets master key, and the database identity is a GitOps-declared user with TLS-only, database-scoped pg_hba rows. Three findings are recorded here because they cost time and would cost it again: pg_hba matches (DATABASE, USER, ADDRESS) so a database-scoped reject row does not restrict the user; Ansible materialises a task’s environment: in the argv of the become wrapper (visible in ps), so secrets must be sourced from a file; and RestrictAddressFamilies needs AF_NETLINK or libuv’s uv_interface_addresses kills a Node service at startup.

[2026-09-25] change | Paperclip service runs as the operator user

Follow-up to the deployment, same day: the service was moved from its dedicated paperclip account to tazpod, because Paperclip is replacing the tmux-launched agents and those agents write to the repository working copies, push through gopass-provided credentials and use the operator’s SSH keys.

Updated:

• details/paperclip-tazpod-detail.md — service user, agent environment section (write access, push credentials via GIT_CONFIG_GLOBAL + GITHUB_TOKEN, sandbox deltas), pet-volume ownership

Why it matters:

The previous shape (a dedicated unprivileged service account, read-only repositories, no credentials) was the safer default but could not do the work the operator wants orchestrated. The current shape reproduces the operator’s own capabilities inside the service, so the trust boundary moved from “the app is contained” to “the app is the operator” — worth remembering when reading any future hardening note about this unit. The push credential still never touches disk: the helper is a function of the environment variable rendered into the 0600 env file.

[2026-09-25] change | First agents and projects on Paperclip (and the wizard’s blind spot)

The first-agent wizard offers only Claude and Codex, and its connection test cannot succeed here, so the CEO was created through the CLI/API instead — pi_local with opencode-go/deepseek-v4.1-flash, plus the six projects (Cluster & Infra, TazPod, Vault & Secrets, Wiki & Docs, Blog, Teaching) all led by that agent.

Updated:

• details/paperclip-tazpod-detail.md — new section “Creating agents and projects when the wizard is not enough”: the CLI recipe, the two traps (provider-qualified model identifier, per-API-base board tokens) and the proof of a successful heartbeat

Why it matters:

Two failures looked like broken configuration and were not: the wizard is simply narrower than the platform, and the model field needs the provider prefix. Both only surface at run time, so the durable lesson recorded here is to trust agent runtime-state after a manual heartbeat rather than the save dialog.

[2026-09-25] lint | Paperclip deployment claims corrected, agent org chart added

A read-only review of the Paperclip deployment (Reviewer) checked the deployment notes against the live system and refuted or found stale several statements. Corrected against the running unit, the env file and the process environment:

Updated:

• details/paperclip-tazpod-detail.md — (1) the “no token on disk” claim is false: GITHUB_TOKEN sits in cleartext in /etc/paperclip/paperclip.env (0600 tazpod:tazpod) and is exported by EnvironmentFile= into every spawned agent (verified via /proc/<MainPID>/environ), while the credential helper, the git config and the remote URL stay secret-free; (2) the unit hardening notes now match the live unit (ProtectHome=no, ReadWritePaths=/workspace /home/tazpod, UMask=0022); (3) the payload/shim row points at /home/tazpod/.local/bin/paperclipai and records that the paperclip account no longer exists; (4) the operations commands no longer use sudo -u paperclip (impossible under NoNewPrivileges); (5) the section now states the blast radius plainly — /workspace write access covers the whole pet volume including /workspace/.paperclip state and its master key, and GITHUB_TOKEN is readable by every agent. Also corrected the stale “all six projects led by the CEO” sentence.
• entities/agent-company.md — new org chart: the CEO plus five reports, each agent’s single-writer repository surface and project leads, the reporting line, and governance in force (per-agent monthly budgets, new-agent approval gate, read-only Reviewer)
• index.md — entity entry for the org chart

Why it matters:

A reader acting on the old text would have misjudged both the sandbox (it is not one) and the secret handling (the push credential does touch disk, and every agent can read it). Matching the page to the live unit and process, and documenting who owns what, is the minimum for the wiki to stay trustworthy. Command anchors used: systemctl cat paperclip, getent passwd paperclip, tr '\0' '\n' < /proc/<MainPID>/environ, paperclipai org get, paperclipai agent list, paperclipai project list.

[2026-09-25] lint | dsh / DeepSeek Harness references audited (no drift found)

Full-text audit of the wiki for dsh / DeepSeek Harness after the decommission recorded earlier the same day. Pattern: grep -rniE '\bdsh\b|deepseek[ -]harness' over index.md, details/, entities/, topics/, operations/, contexts/, concepts/, sources/, analyses/, references/ and docs/; handshake occurrences were excluded as substring noise. wiki/guide/ does not exist in this repository (the runbook/navigation surfaces are operations/, contexts/ and the index).

Real matches, by file:

• details/tazpod-proxmox-runtime-detail.md — the Removed: dsh Web UI section and the “Historical context worth keeping” paragraph. Intentional and accurate; unchanged.
• index.md and entities/tazpod.md — the two catalogue/link descriptions for the CT106 page. Both already read “decommissioned 2026-09-25”, not as a live surface; unchanged.
• details/hindsight-deployment-detail.md — a single upstream-fact aside in gotcha 5 (“Upstream also lists DeepSeek Harness itself among the clients with incomplete session support, discussion #5495”). It documents the OpenCode Go session-header requirement, not a TazLab surface, and is neither stale nor an instruction to use dsh; unchanged.

Excluded as non-matches: deepseek-v4.1-flash (the OpenCode Go model identifier in details/paperclip-tazpod-detail.md and details/tazlab-k8s-teaching-detail.md), “Test harness” (details/ephemeral-castle-golden-image-detail.md), and every handshake.

Live re-verification on CT106 (tazpod-proxmox) today: systemctl status dsh → Unit dsh.service could not be found; command -v dsh → nothing; no @deepseek-ai directory in the tazpod nvm prefix; ss -tln → nothing on 3080/3081; /home/tazpod/.dsh absent; /var/log/dsh-web.log absent. /root/.dsh could not be re-checked as the operator user (permission denied); the decommission entry records it was verified absent during the removal.

Why it matters:

Every remaining mention is either protected history (this log, the intentional “Removed” section) or a single upstream citation, so the audit changed no page body. Recording the search and the classification here means the next agent does not have to repeat it to reach the same conclusion, and the live checks anchor the “decommissioned” claim to today’s container rather than to the text that makes it.

[2026-09-26] update | ~/.pi pet-volume guarantee documented on the CT106 runtime page

Platform commit d7dd4ff (tazzo/tazpod master) moved the pi state directory onto the pet volume. Documented it on the TazPod container runtime page and kept the related pages consistent.

Updated:

• details/tazpod-proxmox-runtime-detail.md — new section “The pi state directory is pet-backed (~/.pi)”: the two state trees (paperclips/<timestamp>-<agentId>.jsonl transcripts and agent/ skills), the path table (/workspace = pve-vm--999--disk--2, canonical /workspace/.paperclip/home/.pi, legacy /workspace/.tazpod/.pi, account path /home/tazpod/.pi as a symlink), the four-step paperclip-pi-home.yml migration/seeding, and the no-op-on-steady-state guard. The Ansible layer list now names layer5-paperclip. It also records a caveat: the .bashrc AI-tool symlink loop still forces .pi to the legacy path, so the canonical target is not stable across interactive shells (both locations are pet-backed, so durability holds).
• details/paperclip-tazpod-detail.md — the heartbeat-session note now states ~/.pi is a pet-volume symlink and links to the runtime page.
• index.md — runtime-page description mentions the pet-backed ~/.pi state directory.

Evidence (live, 2026-09-26): readlink -f /home/tazpod/.pi → /workspace/.tazpod/.pi; findmnt -no SOURCE,TARGET,FSTYPE /workspace → /dev/mapper/pve-vm--999--disk--2 /workspace ext4; /workspace/.paperclip/home not yet created. The .bashrc caveat is read from the deployed /home/tazpod/.bashrc and tazpod/dotfiles/.bashrc.

Why it matters:

The transcripts are the readable record of what each agent did; the wiki now says where they live, why they survive a rebuild, and where the guarantee is currently leaky. The caveat is routed to the Platform Engineer as a follow-up issue rather than left as an assumption.

[2026-09-26] decommission | Hermes Agent VM 501 destroyed, data disk preserved

The board destroyed the unused Hermes Agent VM (VM 501 hermes, 192.168.1.205) on 2026-09-26. The wiki still described it as a live operator surface, so the operational content was replaced by a “Removed” section and the catalogue descriptions were corrected.

Changed:

• entities/hermes.md — decommission banner + Removed: VM 501 decommissioned (2026-09-26) section (what was deleted, the destroy-log evidence, the preserved vm-501-data-orphan disk, how ./create.sh recreates the VM); Overview switched to past tense; Quick Facts gained a Status row; the canonical-pages heading marked historical. Architecture, discoveries and secret paths kept as the record.
• topics/hermes-vm-deployment.md — decommission banner; new Removed section with the same facts and the lvrename rationale; the Dashboard Access subsection marked historical. Architecture/lifecycle kept as the record.
• topics/hermes-lxc-deployment.md — the superseded banner now notes that the KVM successor is decommissioned too.
• index.md — the entity entry and the AI Agent Services section no longer advertise Hermes as current.
• entities/ephemeral-castle.md — the relationship line and the 2026-08-12 note carry the decommission.
• entities/hindsight.md, details/hindsight-deployment-detail.md, topics/hindsight-architecture.md — the per-agent hermes bank is marked dormant and the opencode-go gateway is no longer described as “shared with Hermes” in the present tense.
• topics/tazlab-operating-model.md, topics/tazlab-repository-map.md — repository-table/map rows now state that VM 501 was decommissioned and the data disk is preserved.

Evidence:

• Destroy run log /workspace/hermes-agent/logs/destroy_20260926_075300.log: VM 501 unlinked (unused0: local-lvm:vm-501-disk-2), vm-501-disk-2 renamed to vm-501-data-orphan, vm-501-cloudinit / vm-501-disk-1 / vm-501-disk-0 removed, 1 terraform state instance removed, data disk verified preserved.
• Live verification (2026-09-26, from CT106 tazpod-proxmox): ssh root@192.168.1.200 'qm list | grep -E "^\s*501\s"' → no output (VM 501 NOT PRESENT); ssh root@192.168.1.200 'lvs | grep vm-501' → vm-501-data-orphan pve Vwi-a-tz-- 20.00g data 28.59.

Examined and deliberately left unchanged (accurate history, no drift):

• contexts/INDEX.md and contexts/ephemeral-castle-context.md — records of the 2026-08-12 move out of ephemeral-castle, not claims about the VM being live.
• topics/tazpod-gopass-migration.md — past migration checklist (“22: hermes agent scripts ✅”), historical.
• topics/lxc-storage-crisp-design.md — cites the hermes LXC as provenance for the LXC provisioning pattern, not as a live service.
• topics/hermes-lxc-deployment.md body — CT 105 history (destroyed 2026-08-12), kept for reference.

Why it matters:

A reader acting on the old text would have tried to reach a dashboard and an SSH endpoint that no longer exist. Recording the reversible-preservation detail (vm-501-data-orphan + ./create.sh) means a future operator can restore the surface without a restore step, and the lvrename orphan pattern that made it safe is now anchored to a real decommission instead of only to design notes.

[2026-09-26] ingest | TAZ-19 trusted orchestration host — TazPod LXC provisioning runbook

Published the TAZ-19 operator runbook as durable wiki documentation, after TAZ-12 re-keyed TazPod LXC provisioning to the operator-owned key pinned to tazlab.

Changed:

• topics/tazpod-lxc-orchestration-host.md — new topic page. States the decision (trusted orchestration host is tazlab, 192.168.1.200) and the reason (the tazpod-provision key’s restrict,from="192.168.1.200" pin on CT106 forces the run to originate from tazlab); the control-host requirements table (ansible-core, terraform, gopass + store GPG key, git, openssh-client, both checkouts, runtime.env, ansible.cfg); the provisioning-key contract (/root/.ssh/tazpod-provision, 0600 root:root); the idempotent bootstrap script (tazpod@e38dc17); the ping/--check acceptance commands; the full create.sh run and phase order. No secret values, only paths and names.
• entities/tazpod.md — LXC Runtime section now links the orchestration-host topic.
• details/tazpod-proxmox-runtime-detail.md — Provisioning section gains a “Where the run happens” note; See Also links the new topic.
• topics/tazpod-provisioning-and-dotfiles.md — See Also links the new topic.
• index.md — topic entry under “Operator Tooling (tazpod)”.

Evidence:

• tazzo/tazpod@e38dc17 (“lxc: add the trusted orchestration-host bootstrap (TAZ-19)”) adds runtimes/lxc/scripts/install-orchestration-host.sh (150 lines); the script in the worktree is identical to that commit (git diff e38dc17 -- runtimes/lxc/scripts/install-orchestration-host.sh empty).
• The script and the runbook both carry the from="192.168.1.200" rationale and the tazpod/tazlab-secrets checkout + keypair verification.

Why it matters:

The privileged bootstrap and verification on tazlab are operator actions outside agent reach, so the decision and the exact prerequisites must survive in the wiki: a reader who missed TAZ-19 would otherwise try to run create.sh from a workstation and be rejected by the key pin. Marked explicitly that the runbook records the decision and prerequisites, not an executed result.

[2026-09-27] ingest | Multica — control plane live on tazlab-k8s, daemon registered on CT106

Added the durable page for the agent-orchestration control plane and its runtime, both verified live today, and the operational knowledge the build had to discover to get there.

Changed:

• details/tazlab-k8s-multica-detail.md — new detail page. The two halves and who owns each (Flux+Vault for the control plane, Ansible layer6-multica for the daemon); the manifest table with the registration points; the certificate database identity (four pg_hba rows, DATABASE_URL with sslcert/sslkey/sslrootcert, PKI role db-client-multica, Git-declared grants Job); the seven-key multica-secrets produced by one VaultStaticSecret; the four postRenderer patches with the reason each exists and the warning that an unmatched patch target is a silent no-op; the LAN-only exposure where the frontend proxies the API and WebSocket same-origin; the headless login (DEV-mode code read from the backend log, then POST /auth/verify-code → POST /api/tokens); the image lane (GHCR pinned, Docker Hub mirror not yet published); and the CT106 daemon contract (unit, env file, ~/.multica/config.json as the CLI’s own credential file, OPENCODE_API_KEY/EXA_API_KEY delivery, the two switches that are off for a systemd reason).
• index.md — details entry under “## Details”, next to the teaching page.

Evidence (live, 2026-09-27, from CT106 tazpod-proxmox):

• curl http://192.168.1.240:3000/ → 200 from the VIP; /api/config → daemon_server_url and daemon_app_url = http://192.168.1.240:3000, allow_signup: true, server_version: v0.5.3. Pods multica-multica-backend and multica-multica-frontend 1/1 Running; Service multica-multica-frontend LoadBalancer with EXTERNAL-IP 192.168.1.240; Secret multica-secrets (7 keys) and db-client-multica-tls present.
• Browser session against the running app: /login → code read from kubectl logs deploy/multica-multica-backend -n multica ([DEV] Verification code for taz@tazlab.net: …) → signed in → /tazlab/issues rendered with the agent’s issue; /tazlab/runtimes shows tazpod-proxmox · omp/18.2.7 · Online · 3 runtimes · All idle.
• Daemon: multica version → 0.5.3; systemctl is-active multica-daemon → active, enabled; multica daemon status --output json → workspaces[0].runtimes = 3 ids, agents [pi, omp, antigravity, opencode]; the log shows registered runtime provider=pi|omp|opencode and skip registering runtime: version too old … antigravity 1.1.4 below minimum 1.1.10.
• End-to-end task: issue TAZL-1 assigned to the agent on the omp runtime → task completed in 29 s, 7 tool calls, and the agent’s comment carries the real output of hostname, omp --version, pi --version, multica version, ls /etc/multica.
• Layer idempotency: a second ansible run of the role converged with changed=0.
• Git: tazzo/tazpod@8b5ed4b wires the provider key into the unit.

Why it matters:

The wiki previously described two agent control planes and neither of these facts: that the lab now runs a control plane whose database identity is a certificate (so it survives a rebuild), and that its daemon needs a provider key in the unit environment — pi’s auth.json is empty and omp routes to opencode-go, so without OPENCODE_API_KEY every claimed task dies at the CLI handshake, a failure that looks like an agent bug and is actually a provisioning gap. The page also records the two things that make the login work at all in a lab with no mail relay: RESEND_API_KEY empty ⇒ the code is printed to the backend log, and APP_ENV=production ⇒ MULTICA_DEV_VERIFICATION_CODE is inert.

[2026-09-28] update | Paperclip moved to its own container (CT108) — page created, CT106 marked historical

The wiki still described the agent company as running inside CT106 (tazpod-proxmox), as it was built on 2026-09-25. On 2026-09-26 the company was carried to a dedicated, unprivileged container, CT108 paperclip (192.168.1.208), and CT106’s paperclip.service was stopped and disabled. Nothing in the wiki mentioned CT108, the egress chokepoint, the container’s own gopass store, or the guest’s identities.

Changed:

• details/paperclip-container-detail.md — new Level 3 page. Guest shape (unprivileged, nesting/keyctl off, static address, 32 GB pet volume vm-108-disk-1 → /workspace, raw lxc.cap.drop/cgroup2.io.max written by create.sh over root SSH); the runtimes/lxc-paperclip tree and its six create.sh phases; the five Ansible layers; the unit (canary as ExecStartPre, master key handed over as a path because LoadCredential= cannot work in an unprivileged LXC, hardening, limits); the separate agent gopass store on the data volume, its own inside-generated GPG key, one-way seeding over stdin, core.readonly and the canary’s exit codes; the carry (four artefacts, paperclipai onboard deliberately never run, rollback = swap the unit back); the four identities (paperclip with no sudo and no SSH, the operator-gated Proxmox user/role/token, the Kubernetes paperclip-observer, the Vault AppRole); the tailnet join in userspace mode (TD-093) and what it means; the egress chokepoint (mitmproxy on 127.0.0.1:3128, its CA, the policy allowlist and the two injections, the nftables uid split, the drop-in binding, fail-closed, and the two limits: TD-095 and the absent vault: rule); operations, rollback and the deliberately-absent list.
• details/paperclip-tazpod-detail.md — MOVED banner: the body is kept as the record of the CT106 era (the CLI traps and the blast-radius finding are still worth reading) with the live page linked at the top; the Concept moved to past tense.
• details/tazpod-proxmox-runtime-detail.md — the container’s role corrected: Paperclip ran here 2026-09-25 → 2026-09-26 and its unit is disabled; the layer list now names layer6-multica and layer7-multica-team.
• entities/tazpod.md, entities/agent-company.md, index.md — links and descriptions point at the CT108 page; the agent-company hub states that the Multica team is a separate, Git-declared roster.

Verified live (2026-09-28, from CT106 as tazpod): curl http://192.168.1.208:3100/api/health → {"status":"ok","deploymentMode":"authenticated","deploymentExposure":"private","bootstrapStatus":"ready"}; systemctl status paperclip on CT106 → inactive (dead), disabled. Everything else on the page is read from tazpod/runtimes/lxc-paperclip at its current revision; the guest itself is not SSH-reachable from CT106 (the provisioning key is pinned from="192.168.1.200"), so the in-guest state is documented from the layer that renders it.

Why it matters:

A reader following the old text would operate a control plane that no longer runs there, and would not know that the lab’s agent credentials now pass through a chokepoint, that the container has its own store, or that the tailnet presence is ephemeral. The move is also the answer to the question the old page’s “blast radius” paragraph raised: the agents no longer run with the operator’s whole pet volume writable.

[2026-09-28] lint | tazlab-db aligned to PostgreSQL 17.2, and a two-month-old service claim corrected

The database page still reported PostgreSQL 16; the cluster has been on 17.2 since 2026-09-27, and the page’s “External Service” section pointed at a MetalLB service (tazlab-db-external, 192.168.1.241) that was disabled on 2026-05-23 and no longer exists in the repository.

Changed (details/tazlab-k8s-tazlab-db-detail.md):

• Version row corrected: spec.postgresVersion: 17 / status.postgresVersion: 17, server PostgreSQL 17.2, image ubi8-17.2-1, PGO 5.7.2.
• Users table: eight roles (added hindsight, postgres, paperclip, multica, each with its auth method).
• New section The 17 major upgrade: the ordered Git sequence (5bbd96a → 3ad7659), measured cost (~90 s data work, ~6 min downtime, 80 pods healthy), the two research errors (spec.transferMethod absent from the installed CRD; wrong image tags), the absence of any in-place rollback, and the extension handling (pgaudit at 17.0, vector via ALTER only, one-shot Jobs because databaseInitSQL runs once).
• Backup section: the annotation-driven one-off full backups (pre/post upgrade), why the second one was needed (new WAL timeline, live timeline 3), and why the schedules were suspended rather than left running.
• External Service replaced by Service exposure: tazlab-db-tailnet (Tailscale class, tazlab-db.magellanic-gondola.ts.net, NodePort 32227 pinned) as the only external path, with the old MetalLB service marked disabled.
• Client certificates: six, each in its consumer’s namespace (Grafana, mnemosyne, pgAdmin, tazlab-admin, hindsight, multica).
• pg_hba section rewritten from the live rule list (36 rules): order significance, the (DATABASE, USER, ADDRESS) field-order trap, and Paperclip’s deliberate md5-over-TLS exception.
• New subsection on schema grants for late-added databases (multica-db-grants-job.yaml and the manualSelector: true requirement).
• Known Issues: the stale pgaudit 16.0 catalog row in multica and template1 (observed 2026-09-28, remediation named, handed to the Cluster agent), the no-rollback property of a major upgrade, and the TD-096 dependency stall.
• details/tazlab-k8s-flux-kustomizations-detail.md and index.md — the one-line summaries no longer say Postgres 16.

Verified live (2026-09-28, from CT106): select version() → PostgreSQL 17.2; pg_settings → server_version=17.2, data_directory=/pgdata/pg17, shared_preload_libraries=pgaudit; kubectl get postgrescluster … -o jsonpath → 17 17; kubectl get svc -n tazlab-db → no tazlab-db-external, tazlab-db-tailnet with NodePort 32227; kubectl get vaultpkisecret -A → 8 objects.

Why it matters:

The page is the reference for every consumer of the shared database, and two of its claims were actively wrong — the version, and a connection address that has not existed since May. A reader acting on either would open a change against the wrong target.

[2026-09-28] update | Multica: the Git-declared agent team, the mail path, and the image markers

The Multica page was accurate about the control plane and the daemon but predated the work that landed after it: the agent team is now declared in Git, the login-mail path is configured, and three image/rollout details had been discovered the hard way.

Changed (details/tazlab-k8s-multica-detail.md):

• New section The agent team (declared in Git): the roster as source of truth (configs/multica-team/roster.yml: workspace tazlab, runtime Oh-My-Pi (tazpod-proxmox), the two shared skills lab-team/lab-orchestration), the per-agent defaults (permission: workspace → public_to + workspace invocation target; max_concurrent_tasks: 1 because a handoff is a wakeup, not a call), the eleven agents with their domains, the reconciler’s compare-then-write idempotence (never deletes, stores no id, never touches custom_env/mcp_config/credentials, --dry-run), the layer’s wiring as the operator user, and the push-credential helper rendered into /home/tazpod/.config/git/config.
• Authentication section: the mail path is configured but not armed — resendFromEmail: onboarding@resend.dev replaces the chart default that belongs to a domain this lab does not own, while RESEND_API_KEY is still empty, so the DEV-mode log is what actually works; plus the operator-account requirement for the daemon PAT.
• Image lane rewritten: repository and tag as separate fields, the :tag setter suffix in the image-policy markers (the first automated commit wrote a full image reference into the tag field), the automation’s exact shape, and a new subsection on rolloutRestartTargets naming the release-prefixed Deployments (a rotated secret otherwise never reaches a running process).
• See Also: the sibling-app link now points at the CT108 container page, and the observer identity is linked.

Verified live (2026-09-28): multica agent list --output json → eleven agents, all public_to, all max_concurrent_tasks: 1; multica daemon status --output json → running, cli_version 0.5.3, three runtimes; kubectl get secret -n multica multica-secrets -o json → the same seven keys, RESEND_API_KEY empty; kubectl get helmrelease -n multica → multica-0.5.3+b4f1ca977880, READY.

Why it matters:

The team is the lab’s operating structure — agents that exist only in the control-plane database are objects a rebuild may not bring back, and the page now records where they actually live. The two “silent” failure modes (a marker without :tag, a rollout target with the wrong name) are precisely the kind of thing that looks configured and does nothing.

[2026-09-28] lint | paperclip-observer identity, Vault AppRole, and the teaching test gate

Three facts were live but absent from the wiki: the read-only Kubernetes identity the agent container uses, the lab’s first AppRole trust domain, and the test gate that now blocks the teaching image.

Changed:

• details/tazlab-k8s-paperclip-observer-detail.md — new Level 3 page: why the identity exists (cluster health reports), its shape (ServiceAccount in flux-system, ClusterRole/Binding = view ∪ flux-view-flux-system, get/list/watch only, no secrets, no pods/exec), the nodes grant and its rationale, the token Secret and the operator step that copies it into gopass, how the container renders its kubeconfig from it (never reading the operator’s cluster-admin credential), the infrastructure-agents-paperclip Kustomization (leaf, no dependsOn), verification commands and the revocation path.
• entities/hashicorp-vault.md — new Non-Kubernetes identities section: the auth/approle-agent mount, role paperclip-agent (service token, 1h period, 24h explicit max, single policy, single-use 10m SecretID, CIDR-bound to 192.168.1.208/32), policy agent-paperclip (own KV subtree + its own PKI role; confinement by omission plus explicit denies), the login rate-limit quota, who mints the wrapped SecretID, and the honest status: the chokepoint ships without a vault: rule, so nothing consumes it yet. Also corrected: 8 VaultPKISecrets (was 6) and the mTLS claim (six apps, Paperclip the deliberate exception).
• details/tazlab-k8s-teaching-detail.md — the delivery chain now shows the test job and needs: test (TD-077 closed 2026-09-25), including why the job pins the production Python major and installs the real rendering dependencies.
• index.md — entries for the two new pages.

Verified live (2026-09-28): kubectl get clusterrole,clusterrolebinding paperclip-observer (Flux-owned, created 2026-09-26) and kubectl get sa,secret -n flux-system; vault read auth/approle-agent/role/paperclip-agent + vault auth list + vault policy read agent-paperclip + vault list sys/quotas/rate-limit → mount, role settings, policy and approle-agent-login-rate-limit all as documented; teaching.tazlab.net commit c0b2664 and the current .github/workflows/publish.yml.

Why it matters:

An agent’s cluster credential and a secret-broker identity are exactly the objects whose real reach is invisible from the outside — “read-only” and “one policy” are claims a reader must be able to verify, and now can. The teaching gate is the difference between “the image built” and “the exercises are correct”.

[2026-09-28] lint | stale claims found and NOT fixed (routed, not silently rewritten)

• pgaudit 16.0 in the multica database and in template1 while the binaries are 17.0 — documented as a Known Issue on the database page; the fix (ALTER EXTENSION pgaudit UPDATE) belongs to the Cluster agent.
• paperclip-agent is not among the tailnet peers seen from CT106 (2026-09-28), while the layer and the RUNBOOK join it with --hostname=paperclip-agent; the ephemeral auth key explains it (the node leaves when it goes offline), and the container page now says so instead of asserting reachability. Whether tailscaled inside CT108 is healthy could not be checked — the guest is not SSH-reachable from CT106.
• gopass show -o bootstrap/tailscale/{api-key,oauth-client-id} returns exit 11 (“key not found”) and a full read fails with gpg: public key decryption failed — the onboarding path for re-minting a tailnet auth key is therefore not exercisable from CT106 today. Same class as TD-097 (transient/incorrect gopass reads); left for the Security/TazPod owners rather than documented as fact.
• The chokepoint’s Proxmox rule is dead by design (TD-095) and its vault: rule is absent: both are recorded on the container page as limits, not as working features.

[2026-09-30] update | the teaching graph-reading page is a random graph mill

What changed

TAZLAB-38 released teaching.tazlab.net as commit 74dadcc (the re-land of 1572410 onto the polish(web) frontend refresh) on 2026-09-30: the graph-reading page stopped being a form the operator configures and prints. Every configurator choice now defaults to random, one click produces exactly one graph, and the generator draws the reading the drawn motion can answer — the teacher asks the questions in person.

Changed:

• details/tazlab-k8s-teaching-detail.md — new section The graph-reading page (cinematica-grafici-lettura): the four served controls (Quanti tratti 3/4/5; the segment_kinds control that renders one motion selector per segment with count_from: count; Grandezza sul grafico; Sistema di misura), all defaulting to Casuale; the seed as a page-level Casuale/Numero choice rather than a bare number; what is gone (the reading selector — the generator draws it, and refuses an acceleration asked of an all-uniform motion; the Numero di esercizi field — the page pins count=1; the statement above the graph — show_statement=False, while the statement is still generated and verified for the PDF and the tests); the exact unit-scale table (si, kmh = 18/5, cm = ×100); and the four generator/steps defects the random draw exposed.
• Same page — The descriptor contract — three files, or it is a silent no-op: app/generators/physics/segments.py emits the controls, app/api/schemas.py documents them (ConfigControl, kind ∈ select | segment_kinds, count_from), web/src/config.js renders them and skips an unknown kind with a console warning. A new kind must be added in all three.
• Same page — No frontend test coverage: no test imports web/src/*, web/package.json declares only build/dev, and the test job is pytest with npm ci for KaTeX alone. web/src/ is therefore compiled (Dockerfile stage 1 npm run build, so a syntax error fails the image job) but never tested: a behavioural regression ships green.
• Same page, Delivery Chain — the “a green pipeline means the exercises are correct” claim is now scoped to the Python service, with a pointer to the frontend exception above.
• index.md — the details entry for the page names the new material.

Verification

Live, 2026-09-30, https://teaching.tazlab.net/#/fisica/cinematica/cinematica-grafici-lettura: GET /api/pages returns the page with count: 1, show_statement: false and exactly the four controls described, defaults all random. In a browser the page carries #seed-mode (Casuale/Numero) with #seed disabled while random, a Genera button and no count input; one press yields one card, one <svg>, no .statement and one Passaggi block; a second press on the random seed yields a different graph. Repository side: app/pages.py (registry entry), app/api/schemas.py (ConfigControl), app/generators/physics/segments.py (configurer(), default_options(), _draw_ask, unit systems), web/src/config.js, web/src/app.js, web/src/pages.js, .github/workflows/publish.yml, Dockerfile.

Why it matters

The page had never been described in the wiki — only its cluster footprint was — so nothing there was stale; what was missing was the page itself, and the one fact that changes how the next person works: the configurator is a three-file contract, and the gate that stopped TD-077 covers the Python service only, so a frontend regression can reach the live site green.

Correction (2026-09-30, same day). The two claims above that the frontend is outside CI — “the test job is pytest with npm ci for KaTeX alone” and “the gate that stopped TD-077 covers the Python service only, so a frontend regression can reach the live site green” — were true when written and stopped being true later the same day, when commit df8a7b7 landed the frontend gate. The entry is kept verbatim as the record of the state at the time; see the entry below for what replaced it.

[2026-09-30] update | the teaching publish chain gains the frontend test gate (TD-110)

What changed

df8a7b7 (merged into master as c96ddd1, published and live) gave web/ a vitest suite and put it in the Publish Teaching workflow, which turned the wiki’s “the frontend is outside CI” fact false. Two live pages and one log sentence still said the opposite.

Updated:

• details/tazlab-k8s-teaching-detail.md — the section No frontend test coverage is replaced by a top-level Frontend test gate (it was a ### nested under the graph-reading page, and it is a repo-wide fact the Delivery Chain now points at): web/package.json ("test": "vitest run"), web/vitest.config.js (jsdom, include: ["test/**/*.test.js"], css: false), the two suites and what each asserts (9 in config.test.js, 12 in app.test.js), why the assertions are behavioural and not DOM snapshots, the fixture pin in tests/test_web_fixture.py with its regenerate command, the counts from the run below, and the honest limits (KaTeX’s stylesheet is not loaded; figure.js and formula.js are only reached through pages.js).
• Same page, Delivery Chain — the test job line reads … npm ci (KaTeX + dev deps) → npm test (vitest, web/) → python -m pytest tests -q, and the paragraph that scoped the green-pipeline claim to the Python service now states the gate covers both halves and names the step’s position.
• index.md — the details entry ends with the gate (21 vitest tests, fixtures pinned to /api/pages) instead of “the frontend’s lack of test coverage”.

Verification

Repository at df8a7b7: .github/workflows/publish.yml carries Run the frontend test suite (run: npm test, working-directory: web) between npm ci --no-audit --no-fund and python -m pytest tests -q. Workflow run 36757786129 (head c96ddd1, both jobs green): Test Files 2 passed (2) / Tests 21 passed (21), duration 1.92s; pytest 482 collected with 2 skipped; test 1m31s, build-and-push 1m26s.

Why it matters

The last two sentences of the previous entry were a warning about a gap that no longer existed, on a page an agent reads before touching web/src/. Left alone they would have had the reader looking for a missing gate instead of the npm test step that is in the workflow, and would have sent the next frontend regression back to “the gate that stopped TD-077” — which now catches it.

[2026-10-19] decommission | Paperclip removed

What changed

The Paperclip experiment is over. The guest CT108 (paperclip, 192.168.1.208) and its data volume were destroyed, the shared tazlab-db lost the paperclip database, the role and the four pg_hba rows, the read-only Kubernetes identity (paperclip-observer) was pruned, and the Vault AppRole paperclip-agent went with its policy, quota and mount. Nothing was archived: the operator’s decision.

Pages

details/paperclip-container-detail.md, details/paperclip-tazpod-detail.md, details/tazlab-k8s-paperclip-observer-detail.md and entities/agent-company.md carry a dated historical banner. details/tazlab-k8s-tazlab-db-detail.md no longer lists paperclip as a live consumer and keeps the (DATABASE, USER, ADDRESS) reject-row lesson, now carried by the multica and buzz rows. The published blog post Too Many Agents for tmux keeps its URL and carries a dated closing note.

Why it matters

A decommissioned system that stays described as live is worse than one that is deleted: the next reader provisions against it. The lesson survives; the system does not.

[2026-10-19] decommission | Buzz removed

What changed

The Buzz relay left the cluster: the apps-buzz Kustomization, the Helm release buzz (chart 0.1.9), the deployment and its Redis, the three Services (including buzz-lan on 192.168.1.240:3010), the ServiceMonitor, the NetworkPolicy and the two VSO Secrets are gone; the namespace and its dead probe pod (TD-158) went with them. The shared tazlab-db lost the buzz database, the role and the four pg_hba rows, the Vault KV/PKI/JWT identity was removed, and the nine cluster/buzz/* gopass entries were deleted. On CT106 the layer8 tooling, the agent home and the three buzz* symlinks were removed; the OMP sessions were kept on the operator’s request.

Pages

details/tazlab-k8s-tazlab-db-detail.md lists seven live roles, marks buzz as removed, shows the current pg_hba example and 32 rules. The published article Tre orchestratori keeps its URL with a dated closing note.

Why it matters

The reject-row lesson stays on the multica row; the :3010 port is free while the rest of 192.168.1.240 is untouched.

[2026-10-20] decommission | Multica removed

What changed

The Multica control plane left the cluster: the apps-multica Kustomization and the Helm release multica-multica (chart 0.5.3) went in two commits, the image automation (2 ImageRepository + 2 ImagePolicy + the ImageUpdateAutomation) was removed, the four VSO objects and the multica allowlist entry were pruned, and the namespace went with them. The shared tazlab-db lost the multica database (79 MB), the role and the four pg_hba rows; the Vault KV, PKI role, JWT role and policy were removed; the two infra/multica/* gopass entries were deleted. On CT106 the daemon (multica-daemon.service), /etc/multica, ~/.multica (71 MB), /workspace/.multica (5.2 MB), the CLI and the Multica-rendered git config were removed, and the layer6/layer7 team tooling left tazpod.

Volumes

The three upload volumes — the bound PV and the two orphaned Released copies, all Retain, 5 Gi each — and their Longhorn volumes were deleted explicitly: 15 Gi freed.

Pages

details/tazlab-k8s-multica-detail.md is historical; tazpod-proxmox-runtime-detail.md, tazlab-k8s-flux-kustomizations-detail.md, index.md, entities/tazpod.md, entities/agent-company.md and entities/hashicorp-vault.md were updated (six database roles, 28 pg_hba rules, 13 agents in the historical note, Vault counts). The published Multica article keeps its URL with a dated closing note.

[2026-10-20] deploy | Halloween live at halloween.tazlab.net

What changed

The halloween app was added to tazlab-k8s through the teaching/wiki lane: namespace, base + overlay, Flux Kustomization (dependsOn core + configs), Traefik TLS Ingress + web-only redirect, per-host cert-manager Certificate, and image automation for tazzo/tazlab-halloween (halloween-<N>-<sha>). State is intentionally ephemeral: emptyDir /data + /tmp, no PVC/Longhorn/fsGroup; one replica Recreate; one Uvicorn worker. The Docker Hub image is public; no application secrets.

Verification

https://halloween.tazlab.net/healthz → 200; GET HTTP → 301 / HEAD → 308; HTTPS 200 with a valid Let’s Encrypt chain; Certificate Ready=True; no PVC; full simulator game (two players, wrong password, recovery, victory) passed and reset to lobby. The scanner/audio fix (halloween-2-c91765e…) was delivered automatically by CI → Docker Hub → Flux ImageUpdateAutomation; master-only story voice, one-shot scanner/3-second duplicate guard, and the viewport-fitted master dashboard (halloween-3-f3bc566…).

Pages

New details/tazlab-k8s-halloween-detail.md; updated index.md, topics/tazlab-k8s-image-automation.md and details/tazlab-k8s-image-automation-detail.md.

ambrogio-memory: the service and its contract (2026-10-21)

The lab’s memory left the markdown files and became a service: one Go binary, SQLite, an API on :7810, the skill as the client contract, the internal agent that writes the account of each closed cycle, and the backup pushed to git every thirty minutes. An independent agent tested it and found seven defects (a broken URL in the contract, pagination ignored, documents write-only, the debt text missing from the bundle, no discovery surface, an empty account accepted, and no idempotency on the log); all seven are closed in 66ef795.

Pages

New entities/ambrogio-memory.md, topics/ambrogio-memory-contract.md, details/ambrogio-memory-verbs-detail.md; updated index.md.

ambrogio-memory: the second independent test (2026-10-21)

The same fresh agent retested 11373b3: two real defects (an unknown debt status answered “no debts”; the unknown-parameter refusal covered only three verbs) and four minors (the read-only instance answered 500, the contract’s wording on the close date and the three-word rule, a reused client id with other words, the log rows lost by a restore). All closed, and the summariser now refuses an account that is mostly repetition instead of closing the cycle on it.

ambrogio-memory: the third test round (2026-10-21)

Four rough edges found by the same tester: an empty fourth snapshot, a rename with the wrong field counted as applied, a budget that looked like a ceiling, and render recreating the retired root files. All closed in 0baa1de, together with the two read-storm questions (the archive list carries no bodies; the register pages). The briefing itself had two errors — the restore must run before the service starts, and stderr is empty at the default log level.

ambrogio-memory: the fourth round, the safety net (2026-10-21)

A fresh subagent restored the backup and rendered it again. The restore was not faithful: the export banner replaced the state preamble, every document lost a trailing newline, the archive span and order were lost, and verify compared the wrong tree and could never return zero. Fixed in bf95892, with meta.json per cycle and a byte-identical restore/render round trip. The served skill’s one-byte difference was jq -r, not the service.

ambrogio-memory: the fifth round (2026-10-21)

Two findings: eleven debts were in a status the API itself rejects (“in progress”, with a space, from the old register), invisible to every filter and counted by the open counter; and a list’s count was the page, not the total. Fixed in 0005019 (import normalisation, a one-time UPDATE, and total beside count).

ambrogio-memory: the sixth round (2026-10-21)

Five findings, all in the edges: the search limit was per source, the lists answered with a cursor they refused, a restore renumbered the cycles, the index under-declared the parameters, and verify failed on a memory directory with no export yet. Fixed in 476fdc1; the restore/render round trip stays at zero differences.