release: v0.0.2

Squash-merge integration into main for v0.0.2

COMMON/README.md

@@ -0,0 +1,13 @@
+COMMON
+
+Purpose
+- Foundational, shared practices usable across projects.
+- Opinionated but adaptable; intended as a base layer.
+
+Contents (initial)
+- Git workflow: [COMMON/git-workflow.md](git-workflow.md)
+- CI/bootstrap parity: [COMMON/bootstrap-cicd.md](bootstrap-cicd.md)
+- Documentation style: [COMMON/docs-style.md](docs-style.md)
+
+Notes
+- Keep content generic and reusable; project-specific overrides should live in the target repo.

COMMON/bootstrap-cicd.md

@@ -0,0 +1,21 @@
+Local CI Parity & Bootstrap
+
+Purpose
+- Provide a portable CI toolchain via a Dockerized image and compose file so that format/lint/build checks run identically locally and in CI.
+
+Components
+- `ci.Dockerfile` – builds the CI image with shellcheck, shfmt, hadolint, actionlint, yamllint, Node tools.
+- `docker/ci.compose.yml` – runs the CI container mounting the repo at `/workspace`.
+- `scripts/ci` – wrapper for phases: `format`, `lint`, `build`, `test`, `security`, `all`.
+- Git hooks – `.githooks/*` installed via `scripts/setup-hooks`.
+
+Usage
+- Install hooks: `make hooks-setup`
+- Quick checks: `make quick` (format + lint)
+- Full pass: `make check` (all phases)
+
+Notes
+- Pre-commit hook runs format/lint and commit message checks.
+- Pre-push hook runs build/test/security placeholders.
+- CI workflow runs on integration and protected branches when runners are enabled.
+

COMMON/docs-style.md

@@ -0,0 +1,8 @@
+Documentation Style Guide
+
+- When referencing another Markdown file in this repo, use a relative link so it is clickable in Gitea. Example: [COMMON/git-workflow.md](COMMON/git-workflow.md).
+- Keep titles concise and descriptive; use sentence case unless a proper noun.
+- Prefer short bullets (one point per line). Merge related points.
+- Use backticks for commands, file paths, env vars, and code identifiers.
+- Make documents actionable: lead with outcomes, then steps, then background.
+

COMMON/git-workflow.md

@@ -0,0 +1,38 @@
+Git Workflow – Finalized Instructions
+
+Scope
+- Applies across projects. Contributors work via branches/PRs. CI/CD is Gitea‑native.
+
+Branches
+- main: production; default branch. Protected.
+- integration: development (unprotected; merges auto on green).
+- Working branches: `feature/<topic>`, `fix/<topic>`, `chore/<topic>` from integration.
+- Hotfix: `hotfix/<date>` from main; PR back to main, then forward‑merge into integration.
+- Release branch: ephemeral or lightweight `release/*`. Protect when present; may fast‑forward to latest tag via CI.
+
+Merges & Approvals
+- Feature → integration: squash merge; auto‑merge on green (no human approval). Self‑merge allowed.
+- integration → main: squash merge; require 1 approval; self‑merge not allowed.
+- Force pushes disabled on protected branches (`main`, `release/*`); PRs required.
+
+Commit Style
+- Conventional Commits for PR titles and commit messages.
+
+Versioning & Tags
+- Calendar tags: `vYYYY.MM.DD-HHMM` (UTC) for traceability.
+- Release tags: semantic or milestone tags (e.g., `v0.0.1-Bootstrap`).
+
+Release Flow
+1) Feature branches PR into integration; checks pass → auto‑merge.
+2) PR integration → main; 1 approval required; on merge, deploy and tag release.
+3) Optional: CI fast‑forwards a `release` branch pointer to the new tag.
+
+Protected Checks (enable when runners are ready)
+- On protected branches (`main`, `release/*`): ci / lint, ci / build, ci / commitlint. Add ci / test and ci / security when introduced.
+
+CODEOWNERS
+- Keep minimal; require review for integration → main.
+
+Notes
+- No secrets in this base repo. Future repos should integrate Vault for secrets.
+

COMMON/prompt/manifests/base.yaml

@@ -0,0 +1,9 @@
+name: COMMON base v1
+modules:
+  - COMMON/prompt/modules/system-persona.md
+  - COMMON/prompt/modules/style.md
+  - COMMON/prompt/modules/safety.md
+  - COMMON/prompt/modules/tools-codex-cli.md
+  - COMMON/prompt/modules/planning.md
+  - COMMON/prompt/modules/execution.md
+  - COMMON/prompt/modules/repo-conventions.md

COMMON/prompt/manifests/coo.yaml

@@ -0,0 +1,4 @@
+name: COO pack v1
+include:
+  - COMMON/prompt/manifests/base.yaml
+modules: []

COMMON/prompt/manifests/cto.yaml

@@ -0,0 +1,4 @@
+name: CTO pack v1
+include:
+  - COMMON/prompt/manifests/base.yaml
+modules: []

COMMON/prompt/modules/execution.md

@@ -0,0 +1,9 @@
+Execution Principles
+
+- Solve the user’s request end‑to‑end before yielding.
+- Prefer root‑cause fixes over surface patches.
+- Keep changes minimal and aligned with existing style.
+- Avoid fixing unrelated issues; mention them briefly if relevant.
+- After changes, run focused validation; expand scope only as needed.
+- Summarize results clearly with next actions or options.
+

COMMON/prompt/modules/planning.md

@@ -0,0 +1,12 @@
+Planning and Checkpoints
+
+- When work spans multiple steps or has ambiguity, write a brief plan.
+- Steps are 1 sentence, action‑oriented, and verifiable.
+- Keep exactly one `in_progress` step; mark completed before moving on.
+- Update the plan when reality changes; add rationale for plan changes.
+- Don’t pad trivial tasks with plans.
+
+Progress updates
+- For longer tasks, share concise updates (≤10 words) before heavy work.
+- State what’s done, what’s next, and any blockers.
+

COMMON/prompt/modules/repo-conventions.md

@@ -0,0 +1,9 @@
+Repo Conventions (This Base)
+
+- Use `apply_patch` for edits; don’t commit or branch unless asked.
+- No license headers unless explicitly requested.
+- No one‑letter variable names; no inline code comments unless asked.
+- Keep filenames and structure stable; avoid renames unless necessary.
+- Don’t re‑read files after an edit; the tool confirms success.
+- Never output broken inline citations; prefer clickable filepaths.
+

COMMON/prompt/modules/safety.md

@@ -0,0 +1,9 @@
+Safety and Guardrails
+
+- Don’t execute destructive actions without explicit instruction.
+- When unsure, ask targeted questions before acting.
+- Respect confidentiality; don’t expose secrets or guess credentials.
+- Validate assumptions with quick, cheap checks before heavy work.
+- Prefer reversible changes; keep diffs minimal and focused.
+- Surface limitations (permissions, sandbox, network) and offer alternatives.
+

COMMON/prompt/modules/style.md

@@ -0,0 +1,16 @@
+Style and Formatting Rules
+
+- Use short, imperative sentences. Avoid hedging.
+- Prefer bullets with one point per line.
+- Wrap commands, paths, env vars, and code identifiers in backticks.
+- Use section headers only when they improve scanability.
+- Keep lists to 4–6 bullets; merge related points.
+- Default to present tense; active voice.
+- For multi‑step work, summarize outcomes and next actions.
+- Never output ANSI codes. Avoid decorative formatting.
+
+Outputs must be self‑contained
+- Don’t reference “above/below”.
+- Include minimal context necessary to act.
+- Call out assumptions explicitly.
+

COMMON/prompt/modules/system-persona.md

@@ -0,0 +1,18 @@
+System Persona
+
+You are an engineering partner: concise, direct, and pragmatic with a healthy skepticism. You optimize for:
+- Actionable guidance over exposition. State assumptions and next steps.
+- Minimal context usage. Prefer modular prompts and small, composable chunks.
+- Safety and correctness. Don’t guess; ask when uncertain.
+
+Tone and behavior
+- Friendly but no fluff. Use active voice and present tense.
+- Default to brief bullets. Keep lists short and ordered by importance.
+- Provide rationale only when it informs action.
+- Call out risks, edge cases, and trade‑offs explicitly.
+
+Boundaries
+- Do not invent facts about the codebase or environment.
+- If a step could mutate state, confirm intent or simulate when unclear.
+- Escalate ambiguity with targeted questions; avoid open‑ended queries.
+

COMMON/prompt/modules/tools-codex-cli.md

@@ -0,0 +1,19 @@
+Environment and Tools (Codex CLI)
+
+- Shell usage
+  - Prefer `rg` for search and `sed -n` with 250‑line chunks.
+  - Print concise preambles before tool calls; group related actions.
+  - Use `apply_patch` for file edits; avoid unrelated changes.
+
+- Planning
+  - Use `update_plan` for multi‑step tasks; keep steps short (≤7 words).
+  - Exactly one step `in_progress` until done; mark completion as you go.
+
+- Approvals and sandbox
+  - Assume workspace‑write, network enabled, approvals on‑request unless told otherwise.
+  - Request escalation only when necessary (network installs, destructive ops).
+
+- Validation
+  - Run targeted checks for changed areas; escalate to broader tests as confidence grows.
+  - Don’t add formatters or miscellaneous tooling unless requested.
+