Welcome to the NZRT Wiki Podcast. Today we’re looking at KM Q&A Seed List — All Thirdparties / Projects / Tasks.

This document is a draft seed list for NZRT’s knowledge management system. It hasn’t been pushed to Dolibarr yet — there are currently zero records in the KM module — but this is the source material for a future seeding pass. The data was pulled live from the Dolibarr API on the tenth of June 2026, covering fourteen thirdparties, nineteen projects, and sixty-four standing tasks. TOGAF projects and tasks are intentionally left out of this list and treated as a separate concern.

Before getting into the content, let’s talk about the entry format. Each knowledge management entry has three parts. First, a question — written as something realistic that an agent or team member would actually ask or raise as a ticket. Second, a concise one-to-three sentence answer. And third, a reference pointer to the relevant memory file, configuration section, script, or wiki document where you can dig deeper.

The first major section covers the four business unit projects — the API project for NZRT’s x402 knowledge base, ICS for Internet Consulting Services, ITE for the Iteasel product, and NCS for NZRT Charitable Services. All four share the same four task types. Task one is Marketing and Promotion — pam is the responsible agent, content goes out via WordPress using the wp dot py script, and forum posts go via the forum dot py Python tool. Never use PowerShell for forum posts — session cookies break the CSRF protection. Task two is Technical Development, tracked via system-specific ticket creation scripts with code stored in the matching repository. Task three is Client Delivery, where cas creates the delivery ticket linked to the relevant project and client. Task four is Operations, handled by fin for accounting and sun for procurement.

There’s a specific note for the NCS client delivery task. If a beneficiary submits the intake form but the Dolibarr ticket ends up missing the NCS tag, the problem is in the submission flow. The form posts via AJAX to the WordPress admin handler — not a REST endpoint — and goes through the Dolibarr bridge plugin to create the thirdparty record. The NCS category tag has to be applied via a SQL helper tool because the REST category endpoint isn’t available in this version of Dolibarr.

The second major section covers twelve system and infrastructure projects. For the Obsidian vault, you must read the instructions and schema files before writing any vault note — frontmatter, naming conventions, and cross-linking rules are non-negotiable. For GitHub, you use the gh CLI for GitHub-specific operations and plain git for local commits — never force-push without explicit confirmation. For cPanel and infrastructure, SSH access uses a specific key file and port, restricted to certain network addresses, and on a shared hosting environment you don’t have service restart permissions via SSH — use the cPanel interface instead. For WordPress, content edits go through the REST API via wp dot py, while plugin and theme file changes go through WebDAV. For Dolibarr, the REST API comes first, but for anything it can’t reach — like category tagging or dictionary entries — you drop to SSH and run MySQL directly on the production database. There is no local Dolibarr instance. For Nextcloud, public share links use the OCS sharing API with share type three and read-only permissions, and when uploading TOGAF documents the correct path goes through the Governance subfolder — not directly under the Obsidian root, which is a common mistake. For the Flarum forum, always use Python for posting — a CSRF error is the sign someone used PowerShell instead. For the agent framework, before writing any new script, search the agent repository for an existing ticket creation script first — there are purpose-built scripts with dry-run support for almost every system. And when someone says run pam or run agents, that means cla acts as that agent persona directly, pulls their open Dolibarr tickets, and does the work inline — the run-agents script is deprecated. For Windows operations, PowerShell only — Bash mangles environment variables and path formats. And remember, environment variable values set in one PowerShell call don’t carry over to the next, so set the Dolibarr API key at the top of every command chain that needs it.

The third section covers three vendor and financial projects. BNZ bank transactions are reconciled by fin using Dolibarr’s bank module — currently manual with no automated feed. Bunnings purchases are recorded by sun as supplier invoices against the Bunnings thirdparty. PayPal is treated as a virtual bank account in Dolibarr and reconciled against the payment platform configuration.

On coverage: nineteen of nineteen projects are documented, all sixty-four standing tasks have entries, and fourteen of fifteen thirdparties are covered — The Open Group is excluded because TOGAF is out of scope here. About twenty-five entries are based on documented incidents and existing memory files, and around ten are anticipatory entries based on domain knowledge rather than prior incidents — those are flagged inline. The whole list remains in draft and needs review before any push to the Dolibarr KM module via API.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.