PFVCluster/questions-v1.md

questions-v1.md

Git-tracked question log. The agent writes; the human reviews/edits inline. Version up when a round of answers lands. Synthesize resolved Q&A to Discourse/Redmine. See BASELINE-PROMPT.md §9.

Open questions

Q1. Git remote for meta?

• Context: meta is now a git repo (locally) but has no remote configured. The auto-commit+push policy (baseline §4) can't complete without one.
• Options: (a) new Gitea repo under reachableceo; (b) nest under an existing repo; (c) keep local-only for now.
• Question: Where should meta push?
• Answer: (human)
• Decision: (human/agent)
• Synthesized to: —

Go with option a. The tea command is setup on this workstation (and on ultix-offstage). I guess, also capture that the tea command (and docker login) are setup on my workstations, so that in the future, projects know they can use tea to setup a repo. Also, i want this to be TSYS wide, so it should go under the TSYSGroupCorporate organization. Call the repo: TSYSGroupAIOS . Make it a template repository.

Q2. The bin/ wrapper gap (redmine-cli / discourse-cli) — RESOLVED (discourse)

• Context: PFVCluster's operational.md and AGENTS.md referenced ~/daytoday/redmine/bin/redmine and ~/daytoday/discourse/bin/discourse as the entrypoints — thin shortcut wrappers around the real CLI containers. The actual CLI source lived in ~/projects/KNEL-AIMiddleware/{redmine,discourse}-cli/.
• Question: Are the bin/ wrappers something that should exist, or is the documentation aspirational? Should the template reference these CLIs at all, or stay tool-agnostic?
• Answer: Reference the real container invocation (full path/container name/invoke notes); no duplicate code via shortcut wrappers.
• Decision: No bin/ wrappers. Invoke the real container with docker run. Both CLI sources have been merged into ~/projects/KNEL-AIMiddleware/tooling-cli/{discourse,redmine}/ and PFVCluster's AGENTS.md now invokes them via docker run --env-file ~/.creds/{discourse,redmine}.env. The old ~/daytoday/{discourse,redmine} workspaces and the {discourse,redmine}-cli/ subdirs were removed.
• Synthesized to: PFVCluster AGENTS.md §CLI access; tooling-cli/{discourse,redmine}/

Q3. Should the template ship the Discourse pointer-header pattern?

• Context: PFVCluster migrated 36 in-repo .md files to 10-line pointer stubs citing https://community.turnsys.com/t/<N>. The template currently has scripts/garden.sh that warns about oversized non-Discourse .md, but doesn't enforce the pointer-header format.
• Options: (a) keep it advisory (garden.sh warn only); (b) add an opt-in check-rule that fails if a tracked .md lacks a Discourse URL (excluding AGENTS.md/STATUS.md/etc.); (c) leave it project-local — infra projects want it, personal/business projects don't.
• Question: Which option, and is the assumption in (c) right?
• Answer: (human)
• Decision: (human/agent)
• Synthesized to: —

All projects need it. Discourse/redmine is MANDATORY. No exceptions. What is project specific is which categories to use, and maybe some tagging/topic guidelines etc.

Q4. Sub-agent nudge hook — wanted?

• Context: A sub-agent proposed a non-blocking Crush hook (hooks/nudge-subagent.sh) that emits a stderr reminder after the Nth sequential file read, nudging toward dispatching a sub-agent. Mirrors football's "never read 10+ files sequentially" rule.
• Options: (a) add it (non-blocking, advisory); (b) leave sub-agent use as prose policy only.
• Question: Worth adding, or too noisy?
• Answer: (human)
• Decision: (human/agent)
• Synthesized to: —

Preseving tokens/quota burn is a HUGE priority. It lets me and you do far more work for much longer. Also, I want to move away from harness specific hooks. Git hooks/strong AGENTS.md protocols are strongly preferred. Ill be shifting away from crush over next few weeks to using OpenWebUi/Hermes and a whole swarm of agents with reporting/working relationships etc etc. So anything that is harness specific, get rid of it and make it portable.

Q5. JOURNAL.md vs Discourse audit-log for infra projects

• Context: The template ships docs/JOURNAL.md as the append-only decision log. But PFVCluster (the most mature infra project) has NO JOURNAL.md — it uses Discourse topic #298 as the audit log and Redmine for work tracking. PATTERNS.md §5 noted this divergence.
• Question: Should the template keep JOURNAL.md as the default, with infra projects swapping it for the Discourse-audit-log pattern? Or drop JOURNAL.md entirely in favor of "Discourse is the SoR"?
• Answer: (human)
• Decision: (human/agent)
• Synthesized to: —

No more JOURNAL.md . Redmine is the system of record. JOURNAL.md was a hack I was using until redmine integration was in place. And, yes, discourse can also be used as well. Its a bit of a tricky decision, what should go to redmine vs discourse. I usually keep working notes/evolving status etc in Redmine and then synthesize to Discourse. But thats me as a lowly human :) You figure it out as you go and per project.

Q6. RackRental split-network design on pfv-tsys6/7 [#433]

• Context: TSYS6 and TSYS7 need trunk ports for RackRental. Servers will run a "split network configuration — half on the non-RackRental switch/router side, half on the RackRental switch/router side." RackRental router prevents network loops.
• Question: Is the split per-NIC (one physical NIC to normal network, one to RackRental) or per-VM (some VMs bridge to RackRental, some to normal)? Both TSYS6/7 currently have bond0 with 2 slaves for storage network. How should the bonds be reconfigured?
• Answer: Keep the storage bonds. We need that bandwidth. I believe tsys6,7 have six ethernet ports each? Two on a riser card, and a four port add-on? Or maybe its four total? If four total, the 2 for storage, one for mgmt non rackrental, one trunked to rackrental would be how I want to go.
• Decision: (human/agent)
• Synthesized to: —