installing-enforcementlisted

# Installing Enforcement > **Authoritative for:** when and how to wire the plugin's hard enforcement layer (git hooks + CI) — the soft-vs-hard split and the `/getff:install-enforcement` flow. > **NOT authoritative for:** the installer's deploy mechanics (those live in the project's `install.sh`); the project goal (see the consumer's own README / the framework `README#why-this-exists`). The getff plugin ships in **two layers**. Knowing which one a request needs is the whole job of this skill. ## The two layers | Layer | What it is | How it ships | |---|---|---| | **Soft** (session-scoped) | skills, sub-agents, advisory/inject session hooks — they run *inside the agent session* and *advise* | **already live** the moment `/plugin install` finishes | | **Hard** (repo-scoped) | `.husky` pre-commit/pre-push git hooks, the CI workflow, dev-deps, ESLint/vitest/Stryker configs — they *fail the build* | **opt-in**, via `/getff:install-enforcement` | A plugin can **never** silently wire a consumer's git/CI — so the hard layer is deliberately behind an explicit command, not the install. This is the project's own thesis applied to its packaging: a plugin that *claimed* to install the build-failing enforcement by itself would be exactly the "documents lie" failure the framework exists to prevent. ## When to wire the hard layer Wire it when the user wants violations to **actually block** — a commit rejected, a PR red in CI — not merely surfaced in the session. Signals: "make this fai