Task — engineering-spec@1

install lands the status-sync hook where core.hooksPath points

doneTASK-IMP-083
module improvement · class product · priority p0 · created 2026-07-16 · shipped 2026-07-16
depends on none · blocks none

TASK-IMP-083: install lands the status-sync hook where core.hooksPath points

Summary

The installer writes its status-sync pre-commit hook to .git/hooks/pre-commit unconditionally. Git runs hooks from core.hooksPath when that config is set, so on any repo using a custom hooks directory (the cyberos repo itself is one) the installed hook is inert and the group-A status sync silently dies. Teach install and uninstall to resolve the effective hooks directory and apply the existing ownership rules there, with the summary naming the real path written.

Problem

Step 6b hardcodes the location:

<untrusted_content source="tools/install/install.sh step 6b"> hk="$root/.git/hooks/pre-commit" mkdir -p "$root/.git/hooks" </untrusted_content>

git config core.hooksPath is never read (zero matches in the file). A repo configured with, say, .githooks - a common pattern, and exactly how the cyberos repo is set up - receives a hook git will never execute. The failure is silent: install prints "pre-commit hook v2 installed", the operator believes status sync is live, and docs/status/ quietly lags every backlog write. The install.sh authors have already documented this exact bug class elsewhere in the file ("a guard that skips when its own tool is missing is indistinguishable from success").

Proposed Solution

Resolve the effective hooks directory once: hooks_dir="$(git -C "$root" config core.hooksPath || true)"; empty means .git/hooks as today; a relative value resolves against $root; an absolute value is used as is. Then run the UNCHANGED ownership state machine (absent or ours-outright -> standalone v2; ours-v1-append -> upgrade; foreign -> marked append; ours-v2 -> keep) against <hooks_dir>/pre-commit, mkdir -p-ing the directory exactly as the current code does for .git/hooks. The summary line names the path actually written. Uninstall resolves the same way so it removes or unappends from where install wrote.

Alternatives Considered

Success Metrics

Scope

In scope: hooks-directory resolution in install step 6b and the matching resolution in uninstall; one summary line; hygiene-test scenarios.

Out of scope / Non-Goals

Dependencies

AI Authorship Disclosure

1. Description (normative)

2. Acceptance criteria

3. Edge cases

4. Out of scope / non-goals

Duplicated intentionally with ## Scope for template conformance: hook bodies, framework adapters, and legacy-location migration are untouched.

5. Protected invariants this task must not weaken

End of TASK-IMP-083.

Audit

TASK-IMP-083-hookspath-aware-status-hook spec audit - audit_rubric@2.0

Families walked: FM (all pass - task@1, title <=72, closed enums, ISO created_at, no UNREVIEWED markers, corpus extras additive), SEC (seven H2s present and non-empty, one H1), COND (COND-004 three labeled bullets present; others not triggered), QA (metrics carry baseline/target/deadline grounded in run evidence; >=3 distinct alternatives; Out-of-scope subsection; no unsourced numeric targets; no cross-team claims), SAFE (one sourced block, closed, unnested, clean scan), TRACE (every numbered clause cited by >=1 AC; every AC names a test or a justified ops verification; every test path is in new_files or exists on disk; draft status exempts TRACE-004; no deferred slices).

ISSUE ISS-001 (QA-006/TRACE-001, fixed): authoring investigation of uninstall.sh revealed its ownership test is still the head-5 heuristic install.sh condemns (uninstall.sh:24-28) - a short foreign hook carrying our appended block would be DELETED whole. Clause 1.5 extended, AC 8 + edge-case row added. This is the audit loop catching a live defect. ISSUE ISS-002 (QA-008, wontfix-info): "husky adapters" named in Non-Goals reference a tool family, not a team dependency; generic hooksPath resolution covers their directories.

SUMMARY verdict: pass issues_open: 0 issues_human: 0 iterations: 2 next_action: ship

§gate-log

Populated during implementation (ship-tasks testing phase).