Files
TSYSGroupAIOS/questions-v1.md
T
mrcharles 9dc85ba41e refactor: go harness-agnostic — drop Crush hooks, enforce Discourse SoR
Apply answers to questions-v1.md (Q1–Q5):

- Q4: Remove crush.json and hooks/ entirely. All enforcement is now portable
  via git hooks (pre-commit/pre-push) + check-rules.sh + AGENTS.md prose.
  Works under Crush, OpenWebUI, Hermes, or any agent framework.
- Q5: Remove docs/JOURNAL.md. Redmine is the system of record for work;
  Discourse for docs. JOURNAL.md was a stopgap.
- Q3: Add mandatory Discourse pointer-header check to check-rules.sh. Any
  non-exempt tracked .md without a Discourse URL FAILs. All projects, no
  exceptions.
- Q2: Reference real CLI container invocation paths
  (KNEL-AIMiddleware/{redmine,discourse}-cli/) in AGENTS.md instead of the
  missing bin/ shortcuts.
- Q1: Note tea + docker login are preconfigured on TSYS workstations.

Also: make test default is now no-op pass so the template self-validates;
make validate now passes clean on the repo itself (17 PASS / 0 FAIL).

💘 Generated with Crush

Assisted-by: Crush via Crush <crush@charm.land>
2026-08-07 12:04:04 -05:00

57 lines
4.9 KiB
Markdown

# 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)
- **Context:** PFVCluster's operational.md and AGENTS.md reference `~/daytoday/redmine/bin/redmine` and `~/daytoday/discourse/bin/discourse` as the entrypoints. But `ls ~/daytoday/{redmine,discourse}/` shows only `.gitignore` + `AGENTS.md` (+ MIGRATION-PLAN.md for discourse) — no `bin/`, no Dockerfile. The actual CLI source lives in `~/projects/KNEL-AIMiddleware/{redmine,discourse}-cli/`.
- **Question:** Are the `bin/` wrappers something that should exist (and were lost / never committed), or is the documentation aspirational? Should the template reference these CLIs at all, or stay tool-agnostic?
- **Answer:** _(human)_
- **Decision:** _(human/agent)_
- **Synthesized to:** —
The clis should exist. Maybe the AGENTS.md reference the actual paths? I dont need duplicate code. I think i was using the directories as kind of "shortcuts" vs the ~/projects/... path every time. So, for this repo, reference the full path/container name/invoke notes. Does that make sense?
### 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.