- audit/phase-one + phase-two: security audit briefs, findings, credential-rotation plan, Docker-USER hardening scripts, rollback refs - disaster-recovery/restore-test-log.md + backup-dr-audit-2026-08-10.md - clients/ (modelortho SEO audit, ai-biz-dev competitive landscape), notes/ (tiktok strategy) - projects/: front-desk-voice-agent, seo-visibility-checker product plan, hotnow-savannah HTML, resend-transactional-email, backup-dashboard-enhancements, code-review-graph, seo-ci-architecture - proposals/verdicttank/: architecture v4.0, methodology, judge-pool review, consolidation reasoning, cross-check review - docs/super-search/firecrawl-provider-strategy.md - updates: CHANGELOG, model-chain, projects-master-readme, intelsight.io - .gitignore: exclude nested standalone repos (seo-tool, venturebuilt)
99 lines
4.7 KiB
Markdown
99 lines
4.7 KiB
Markdown
# Skill Spec - ITPP Policy-Adherence Gate
|
|
|
|
**Type:** Documentation-only spec (no skill is created by Phase One). Actual implementation is a Phase Two task, pending Germaine's go-ahead.
|
|
**Purpose:** A Hermes skill that makes Sho'Nuff the enforcement point for the Policy & Procedure Document, so policy is applied consistently rather than remembered ad hoc.
|
|
|
|
---
|
|
|
|
## 1. Name & Placement
|
|
|
|
- **Skill name:** `itpp-policy-adherence` (or `policy-adherence-gate`)
|
|
- **Category:** `devops` (alongside `governance-and-honesty`, `subagent-verification`)
|
|
- **Location:** `~/.hermes/skills/devops/itpp-policy-adherence/SKILL.md`
|
|
- **Reference dependency:** loads the Policy & Procedure Document and the Running Exemptions Document from `/root/projects/itpp-infrastructure/audit/phase-one/` (or their canonical home once promoted).
|
|
|
|
---
|
|
|
|
## 2. Trigger Conditions
|
|
|
|
The skill activates whenever a user request or an automated job would, if executed, do any of the following:
|
|
|
|
- Modify production configuration on Core/app1/app2/app3/app1-bu/wphost02.
|
|
- Rotate, create, store, or transmit a credential.
|
|
- Change a firewall rule, DNS record, Tailscale ACL, or Docker port binding.
|
|
- Alter a backup target, backup schedule, or the standby sync.
|
|
- Add a new host, site, or product to the estate.
|
|
- Deprecate, decommission, or rename any infrastructure component.
|
|
- Publish or change anything on `docs.itpropartner.com` or the docs repo.
|
|
- Introduce a service that would bind to 0.0.0.0 or bypass the reverse proxy.
|
|
|
|
---
|
|
|
|
## 3. Behavior
|
|
|
|
When triggered, the skill runs a policy check **before** acting:
|
|
|
|
1. **Classify** the request against the Policy & Procedure Document sections (§2 Change Management, §3 Docs-Sync, §4 Backup/DR, §5 Access, §6 Segmentation, §7 Cadence).
|
|
2. **Compliant** → proceed normally, and record the action per §2 (what / who / when / rollback).
|
|
3. **Departure** → do **not** execute. Raise an exemption request:
|
|
- State the provision being departed from.
|
|
- Request a business justification.
|
|
- **Only Germaine may authorize** the departure. No self-approval, no "it's low stakes, I'll just do it."
|
|
4. **Unknown / ambiguous** → ask Germaine rather than guessing, consistent with the standing no-fabrication rule.
|
|
|
|
---
|
|
|
|
## 4. Running Exemptions Document - Schema
|
|
|
|
The skill maintains a single append-only document (e.g. `exemptions.md` alongside the policy doc). Each entry:
|
|
|
|
```markdown
|
|
## EX-<seq>
|
|
|
|
- **Date:** YYYY-MM-DD
|
|
- **Requester:** <who asked / what job asked>
|
|
- **Provision departed from:** <Policy & Procedure §X.Y - short title>
|
|
- **Request + business justification:** <what is being asked, why>
|
|
- **Germaine authorization:** <approve / deny / deferred, with date>
|
|
- **Type:** one-time | ongoing
|
|
- **Follow-up:** <review date for ongoing; or "closed" with closure date for one-time>
|
|
```
|
|
|
|
**Rules:**
|
|
- Every exemption is append-only. Existing entries are never edited to change the authorization; supersession adds a new entry.
|
|
- Ongoing exemptions carry a follow-up review date; a review is triggered when that date passes.
|
|
- The Phase One public-repo deferral is the seed entry:
|
|
|
|
```markdown
|
|
## EX-001
|
|
|
|
- **Date:** 2026-08-13
|
|
- **Requester:** Sho'Nuff (conductor, Phase One audit - Git-A finding)
|
|
- **Provision departed from:** §5 Access / §8 Exemptions - live credential in public repo `itpp-infrastructure`
|
|
- **Request + business justification:** Immediate lockdown (private + history scrub) of a public repo re-leaking admin passwords; surfaced as a Critical finding under the "cannot wait" policy.
|
|
- **Germaine authorization:** deferred - "leave the repo alone for now"
|
|
- **Type:** one-time (deferral)
|
|
- **Follow-up:** re-surface at Phase Two planning
|
|
```
|
|
|
|
---
|
|
|
|
## 5. Integration Notes
|
|
|
|
- The skill does **not** itself enforce anything mechanically - it is a decision gate that runs in Sho'Nuff's reasoning before any privileged action, and it surfaces exemption requests to Germaine.
|
|
- It references, but does not duplicate, the Policy & Procedure Document. The policy doc is the source of truth; the skill is the tripwire that consults it.
|
|
- It composes with the existing `governance-and-honesty` and `subagent-verification` skills: those govern output integrity and subagent checking; this one governs *whether a privileged action is even permitted*.
|
|
|
|
---
|
|
|
|
## 6. Acceptance Criteria (for the eventual implementation)
|
|
|
|
1. A request to change an app1 firewall rule with no exemption raises an exemption request to Germaine instead of executing.
|
|
2. A compliant change (e.g. fixing the LiteLLM `pg_dump` target) proceeds and is recorded per §2.
|
|
3. EX-001 is present in the Running Exemptions Document and re-surfaces at Phase Two planning.
|
|
4. The skill never self-authorizes an exemption; Germaine's explicit approval is always required for a departure.
|
|
|
|
---
|
|
|
|
*End of Skill Spec.*
|