Fresh-project onboarding: interview→charter governance silently doesn't land; `init --here` hint is a nonexistent flag; charter errors cite display-only charter.md

## Summary

The fresh-project onboarding path — `init` → `verify` → charter interview → charter generate → charter context/status — has a broken and misleading feedback loop. A user completes the structured charter interview, yet the governance/activation they answered for **silently never lands**: generated governance comes out zeroed even though `answers.yaml` is populated, stack detection correctly identifies the project's real stack but does not gate activation, `generate` **reports** a large selection while the persisted charter records `[]`, and `charter context`/`status` give no confirmation of what policy (if any) is actually in effect. On top of that, the remediation hint the user is most likely to hit (drifted managed skills) points them at a **flag that does not exist** (`spec-kitty init --here`), and charter-not-found errors cite the **display-only** `charter.md` rather than the authoritative `charter.yaml` bundle.

This is one cluster of defects on a single seam (first-run onboarding + charter activation), filed as one ticket with per-bug sections. The headline is Bug 3; Bugs 1, 2, and 4 are supporting onboarding-path defects in the same feedback loop.

## Environment

- Version: reported on **v3.2.6**; all evidence below re-verified on branch state **v3.2.7rc1**.
- Project: fresh **TypeScript / React** project (not the Python/generic default stack).
- Reporter: a **Kiro** end-user (first-run experience), English/Dutch.
- Trigger: standard onboarding path `init` → `verify` → `charter interview` → `charter generate` → `charter context`/`status`.

---

## Bug 1 — `spec-kitty init --here` is advertised (docstring + verify remediation hint) but the flag does not exist

**Observed behavior:** After `verify` reported drifted managed skills, the user followed the printed remediation and ran `spec-kitty init --here`, which failed with an unknown-flag error. Falling back to `spec-kitty init ` errored "Directory already exists" with no pointer to the correct current-directory recovery.

**Evidence:**
- `src/specify_cli/__init__.py:19` — the module usage docstring lists `spec-kitty init --here` as a supported form.
- `src/specify_cli/verify_enhanced.py:454` — on drifted managed skills, verify tells the user: `"Managed skills: some files are missing or drifted (run spec-kitty init --here to restore)"`.
- `src/specify_cli/cli/commands/init.py:537` — `init()` accepts **only** a positional `project_name` plus `--ai` and `--non-interactive`. There is **no** `--here` option.
- `src/specify_cli/cli/commands/init.py:554-559` — current-directory init is the bare `spec-kitty init` (or `spec-kitty init .`, normalized to `project_name = None`), never `--here`.
- `src/specify_cli/cli/commands/init.py:573-582` — `init ` raises a "Directory ... already exists" panel with no hint toward the current-dir invocation.

**Impact:** The single remediation string a first-run user is most likely to encounter is a **dead end** — it names a flag that cannot be parsed. Highest-impact single fix in the cluster: the `verify_enhanced.py:454` remediation string.

---

## Bug 2 — charter resolution errors point at the display-only `charter.md`, not the authoritative `charter.yaml`

**Observed behavior:** `charter status` (and related resolution) reported "Charter not found" pointing at the legacy/display path even though the project's real charter bundle existed.

**Evidence:**
- `src/specify_cli/cli/commands/charter/_common.py:28-42` — `_resolve_charter_path` resolves **only** `.kittify/charter/charter.md` and raises `"Charter not found at …/charter.md"`.
- `src/specify_cli/cli/commands/charter/_common.py:45-56` — the sibling `_resolve_charter_bundle_path` docstring states explicitly that `charter.md` is **display-only** and `charter.yaml` is the **authoritative bundle**.

Consequence: a project whose authoritative `charter.yaml` exists but whose display `charter.md` is absent (or was deleted) is told, misleadingly, that no charter exists — the error cites the non-authoritative artifact.

**Impact:** Onboarding users cannot trust `charter status` to report whether governance exists, and the error steers them at the wrong file.

**Related:** #3948 ("Plan and analyze prompts drift from CLI: setup payload claim and wrong charter path") — likely shares the display-vs-authoritative-path root cause; cross-link.

---

## Bug 3 (core) — interview → generate does not populate governance/activation; reported selections diverge from the persisted charter; stack detection does not gate activation

**Observed behavior:** The user completed the structured interview with real answers, ran `charter generate`, and got a charter whose governance was **zeroed** — while `generate`'s own summary claimed a large selection had been made, and the activated doctrine matched the built-in Python default rather than the detected TypeScript stack.

**Root cause (single design gap):** activation is derived **solely** from `.kittify/config.yaml` `activated_*`. Neither the interview answers nor stack detection is ever wired into `config.yaml activated_*` during a fresh charter flow, so a fresh project takes the built-in default set regardless of what was answered or detected.

**Evidence:**
- `src/specify_cli/cli/commands/charter/generate.py:359-367` — comment states activation derives solely from `.kittify/config.yaml` `activated_*` and that `interview_data` "**is no longer read for activation selection**" (WP02 FR-001/FR-002 refactor); interview answers flow through only as the interview record and non-doctrine prose (testing/quality/deployment).
- `src/specify_cli/cli/commands/charter/generate.py:357` — `provision_mission_type_activations(repo_root)` seeds the **built-in default** activation set (Python/generic) irrespective of detected stack.
- `src/specify_cli/cli/commands/charter/generate.py:434-435` — the JSON summary reports `selected_paradigms` / `selected_directives` sourced from `compiled.*`, which is what the user saw as "selected 13 paradigms + 34 directives".
- `src/specify_cli/cli/commands/charter/status.py:184-192` — stack detection **does** correctly surface the real stack (`stack=…`, `lang=…`, frameworks/test_frameworks counts) from code/evidence signals — proving detection works but is never fed into activation.

**Observed consequences, all traceable to this one gap:**
1. `answers.yaml` had coverage / framework / linting / commit-convention filled, yet generated governance came out zeroed with `directives: []`.
2. `generate` reported "selected 13 paradigms + 34 directives" (from `compiled.selected_*`), but persisted `governance.charter.selected_*` and `activations` are `[]` — a **reported-vs-persisted mismatch**, and the file offers no way to tell what is actually active.
3. Stack detection correctly sniffed typescript + vitest, yet activated doctrine is python-mutation-tools / DDD / Git-Flow / C4. **Detection does not gate activation.**
4. `charter context` shows an empty `Policy Summary: - >` and never echoes hand-authored governance/directives — no confirmation the policy is in effect.

**Impact:** This is the credibility-damaging core. A user who diligently completes the structured interview receives governance that ignores their answers and their stack, with a success message that contradicts the persisted file and no surface that confirms what is active.

**Related (neighbors, NOT duplicates):**
- #3908 ("Compact charter context and runtime prompts lose activated governance while reporting success") — same symptom family (success reported while governance is absent), but #3908 is about **losing already-activated** governance, whereas this bug is that governance is **never activated** from interview/stack on a fresh project. Different root cause.
- #3920 ("Init command rendering precedes final REASONS activation…") — adjacent ordering/activation-timing concern on the init path.

---

## Bug 4 (minor note — "while you're in here") — `safe-commit` warns `--to-branch` becomes required in v3.3, but the documented skill example omits it

**Evidence:** `src/specify_cli/cli/commands/safe_commit_cmd.py` — the generic path emits a stderr deprecation `"warning: --to-branch will be required in v3.3; pass it explicitly"` (see `safe_commit_cmd.py:388`, contract at `:20-23`, option at `:433-439`). The skill's documented example does not pass `--to-branch`, so following the docs produces a deprecation warning.

**Impact:** Low. Documentation/skill example is out of step with the emitted warning; fold in as a note, not the headline.

---

## Why P1

Onboarding is the first-run experience and the moment a new user forms trust in the tool.

- The **structured interview policy silently does not apply** — the user's diligent answers and correct stack detection are discarded, and the tool reports success anyway (Bug 3). Silent divergence between reported and persisted state is high-credibility damage.
- **Nothing confirms active governance** — `charter context`/`status` give an empty policy summary, so the user cannot even detect the failure themselves.
- The most likely remediation hint is a **dead end** pointing at a nonexistent flag (Bug 1), and charter presence errors point at the **wrong file** (Bug 2).

Together these make a fresh project's governance quietly wrong with no honest signal — squarely a P1 onboarding-integrity defect, not cosmetic.

## Proposed acceptance (outcomes, maintainer picks the implementation)

- **Interview/stack → activation:** a fresh charter flow must either (a) populate `.kittify/config.yaml` `activated_*` from the interview answers and/or detected stack, **or** (b) stop the interview from collecting governance-shaped answers it then discards. The current state — collect, report, discard — is not acceptable.
- **Reported == persisted:** the selection `generate` reports (`selected_paradigms` / `selected_directives`) must match what the persisted charter actually records/activates; no summary may claim a selection the file does not hold.
- **Detection gates activation:** when stack detection identifies a stack (e.g. typescript + vitest), the activated doctrine must reflect it rather than the built-in Python/generic default — or the default must be surfaced explicitly as a fallback the user can see and correct.
- **Confirmation surface:** `charter context` / `charter status` must confirm the active policy (non-empty policy summary echoing active governance/directives), so a user can verify what is in effect.
- **Honest remediation + docstrings:** the `verify` drifted-skills hint (`verify_enhanced.py:454`) and the `init` usage docstring (`__init__.py:19`) must name a real invocation (`spec-kitty init` / `spec-kitty init .`), and the `init ` conflict error should point at the correct current-dir recovery.
- **Authoritative charter resolution:** charter-not-found / presence errors must resolve against the authoritative `charter.yaml` bundle, not report absence based solely on the display-only `charter.md`.
- **safe-commit docs:** the documented skill example should pass `--to-branch` (or the docs should note the v3.3 deprecation) so following the docs does not emit a warning.

## Related issues

- #3908 — neighbor, **not** duplicate (losing already-activated governance vs. never activating it; same symptom family, different root cause).
- #3920 — neighbor (init-time activation ordering).
- #3948 — likely shares Bug 2's display-vs-authoritative charter-path root cause.

---

*Filed by Planner Priti (planner/triage profile). All file:line citations verified against branch state v3.2.7rc1.*

Start with charter/generate.py and the .kittify/config.yaml activation flow, then inspect charter/status.py and charter/_common.py for persisted-state reporting and authoritative resolution. Review verify_enhanced.py and cli/commands/init.py for the invalid remediation path. Reproduce the fresh TypeScript/React onboarding flow; done when reported and persisted governance agree, active policy is visible, and all remediation and charter paths are valid.

Written by the indexing model from the issue text.