docs(questions): add Followup 2025-17-09-14:33 for CLI UX, templates, prompts, config, safety

collab/questions/00-bootstrap.md

@@ -94,33 +94,102 @@ Lets say Ubuntu 22.04/Debian 12 or later.
 
 ### Wrapper naming & install
 1. Wrapper name: prefer `codex-helper` or `CodexHelper`? Install path (e.g., `~/bin`)?
+
+CodexHelper please
+This will not be "installed". It will be cloned , the CodexHelper shell script added to the users path. The CodexHelper is only an entrypoint and wrapper around codex-cli (CodexHelper should have a bootstrap function to ensure codex-cli is actually installed of course). The CodexHelper script will be called from within a project directory somewhere else on the filesystem. It may or may not be a git repository working directory.
+
 2. Binary discovery: try `which codex` first, then `codex-cli`? Allow override via `CODEX_BIN` env var?
 
+Sure.
+
 ### Modes and templates
 3. Repo layout: store modes under `modes/<name>/` with `system.md`, `mode.md`, `defaults.yaml`? OK?
+
+Yes. However the system prompt is shared across all modes. It will be about a dozen rules or so that I want applied to all of my projects.
+
+Perhaps we should allow a mode specific system prompt as well? I don't know enough about how prompts are chained or stacked to fully
+understand the implications. 
+
+Basically I want a base set of global rules, a mode set of rules and then a project prompt (which won't be rules per se (well maybe coding styles or something)) but more of a narrative/descriptive set of material telling codex WHAT to do (not so much how to do it)
+
+
 4. Project scaffolding: create templates under `templates/project/<mode>/...` and generate into user-specified target path? OK?
+
+I am not sure what this means? Give me some examples?
+
 5. Example project: include only one example (resume rewriter). Where should we place the example template in this repo?
 
+Actually forget all about the example project. I'm going to do that in a different repository. I want this project/repo to be purely code/prompts.
+
 ### Project structure & config
 6. Config format: YAML vs JSON vs TOML? Preference? (YAML easier for markdown-heavy prompts.)
 7. Single file vs split: prefer `project.yaml` in project root, or split into `prompts/` + `codex.yaml`?
 8. Precedence confirm: CLI > env > project > mode > global defaults — confirm this exact order?
 9. Entrypoint script: generate `codex.sh` in project root that resolves config and runs `codex`? Name OK?
 
+I think that all looks good. I'll leave it to your discretion. I need to get a "feel" for the usage and tweak as we go.
+
 ### CLI UX
 10. Subcommands: propose `new-project`, `new-mode`, and `run`. Example:
     - `codex-helper new-project --mode SAASApp --name my-app --path ~/dev/my-app`
     - `codex-helper new-mode --name SAASApp`
     - `codex-helper run` (inside a project dir)
     Approve?
+
+
 11. Flags: always accept `--mode`, `--prompt-file`, `--config`, `--sandbox`, `--full-auto` to pass through to codex. Anything else?
 12. Non-interactive default: default non-interactive; add `--interactive` to prompt for missing values. Approve?
 
+Yes I think that all looks good.
+
 ### Outputs, safety, and licensing
 13. Runs directory: write transcripts/logs to `<project>/runs/<timestamp>/...`. Approve?
+
+Well remember, we don't allow the script to run from inside the repo checkout directory except to create new modes. 
+
 14. Safety: default to no destructive actions; require `--force` to overwrite existing files; never run `git push` for user projects. Approve and add anything else?
+
+User projects will never be created in this repo. 
+
 15. Dependencies: are `bash`, `git`, and one of `jq` (JSON) or `yq` (YAML) acceptable? Preference?
+
+Sure. I suppose we should settle on either json or yaml? Supporting both seems like more work?
+
 16. Licensing in generated projects: include no default LICENSE, or include a template with TODO? Preference?
 
+The user will pick a license. We won't be invovled.
+
 ### Roadmap
 17. We will add `docs/ROADMAP.md` and defer MCP integration. Any additional roadmap items you want listed now?
+
+No
+
+## Followup 2025-17-09-14:33
+
+### CLI UX and workflow
+1. Subcommands vs flags-only: prefer simple flags (e.g., `CodexHelper --mode SAASApp --new-project`) or explicit subcommands (`CodexHelper new-project --mode SAASApp`)? Please pick one.
+2. Project creation flow: confirm that `CodexHelper` runs from any project dir outside this repo to scaffold project files for a chosen mode; this repo is only for modes and the wrapper. Correct?
+
+### Templates and scaffolding
+3. Examples for project scaffolding (pick what you want generated initially):
+   - prompts/: `project.md` (narrative), optional `style.md`
+   - config: `codex.yaml` (mode selection, settings, MCP placeholders)
+   - helper: `codex.sh` entrypoint that resolves config and runs `codex`
+   - runs/: created on first run, ignored by VCS
+   Keep/delete/adjust which of these?
+
+### Prompts composition
+4. Confirm stacking order: Global system rules → Mode rules → Project narrative prompt. OK?
+5. Locations proposal: `prompts/global/system.md` (repo-wide), `modes/<name>/system.md` (optional overlay), `modes/<name>/mode.md` (mode rules), project `prompts/project.md`. Approve?
+
+### Config and tooling
+6. Format/tooling: choose YAML + `yq` as the single supported format/tool. Approve?
+7. Precedence final confirm: CLI > env > project > mode > global defaults. Approve?
+8. Binary detection: detect `codex` then `codex-cli`, override with `CODEX_BIN`. On missing, print instructions; no auto-install. Approve?
+
+### Outputs and safety
+9. Runs location: always `<cwd>/runs/<timestamp>/...` (never in this repo unless creating modes). Approve?
+10. Safety: never overwrite without `--force`; never run `git push` in user projects. Anything else to lock down?
+
+### Install convenience
+11. Provide optional `bin/install.sh` to symlink `CodexHelper` into `~/bin` (no sudo). Include or skip?