@event4u/agent-config 2.25.0 → 2.26.0

package/.agent-src/rules/domain-safety-retention-finance.md

@@ -1,48 +0,0 @@
----
-type: "auto"
-tier: "2a"
-description: "Finance data retention guidance — flag jurisdiction dependence, default to longest applicable retention, never delete records under audit hold"
-source: package
-triggers:
-  - keyword: "retention policy"
-  - keyword: "data retention"
-  - keyword: "record retention"
-  - keyword: "delete financial"
-  - keyword: "purge invoice"
-  - phrase: "how long should we keep"
-  - phrase: "when can we delete"
-routes_to:
-  - "skill:data-handling-judgment"
-applies_to_user_types:
-  - "finance"
-  - "ops"
----
-
-# Domain Safety — Finance Record Retention
-
-## Iron Law
-
-```
-WHEN ASKED HOW LONG TO KEEP FINANCIAL RECORDS — NAME THE JURISDICTION GAP
-AND DEFAULT TO THE LONGEST APPLICABLE FLOOR. NEVER RECOMMEND DELETION
-OF RECORDS UNDER AUDIT HOLD, LITIGATION HOLD, OR REGULATORY INQUIRY.
-```
-
-Retention questions look operational but are regulatory minefields: tax-authority floors, statute-of-limitations windows, GAAP / IFRS requirements, and contractual obligations stack non-trivially. A wrong "delete after 3 years" recommendation can destroy evidence in a future tax audit or litigation.
-
-## Required surface in every retention answer
-
-1. **Jurisdiction gap.** *"Retention floor depends on jurisdiction — name yours."* Then provide ranges if known (e.g., US-federal-tax: 7 years from filing; EU VAT: 10 years in DE/AT, 6 in UK post-Brexit).
-2. **Audit / litigation hold check.** *"If any of these apply, do not delete: open tax audit, pending litigation, regulatory inquiry, contractual record-keeping clause, criminal investigation."*
-3. **Longest-floor default.** When multiple floors apply, the longest wins. Document the chosen floor.
-4. **Disclaimer.** Append the financial-disclaimer footer from `domain-safety-disclaimer-financial`.
-
-## Refusal triggers
-
-- *"Delete all invoices older than 2 years"* (without jurisdiction context) → refuse + ask the jurisdiction-gap question.
-- *"We're under SEC investigation — can we clean up old emails?"* → hard refuse; flag spoliation risk; redirect to counsel.
-
-## See also
-
-- `skill:data-handling-judgment` — retention + transfer cognition.
-- `domain-safety-disclaimer-financial` — companion advisory disclaimer.

package/.agent-src/rules/domain-safety-retention-support.md

@@ -1,55 +0,0 @@
----
-type: "auto"
-tier: "2a"
-description: "Support / CRM data retention guidance — surface DSR-readiness, consent-window expiry, ticket-body retention vs. analytics aggregate retention"
-source: package
-triggers:
-  - keyword: "ticket retention"
-  - keyword: "CRM retention"
-  - keyword: "DSAR"
-  - keyword: "data subject request"
-  - keyword: "right to be forgotten"
-  - phrase: "delete customer data"
-  - phrase: "how long do we keep tickets"
-routes_to:
-  - "skill:data-handling-judgment"
-  - "skill:privacy-review"
-applies_to_user_types:
-  - "support"
-  - "gtm"
----
-
-# Domain Safety — Support / CRM Retention
-
-## Iron Law
-
-```
-SUPPORT-DATA RETENTION ANSWERS DISTINGUISH RAW TICKET BODY (PII-LADEN)
-FROM AGGREGATE ANALYTICS (DE-IDENTIFIED). DSR-READINESS IS THE FLOOR,
-NOT THE CEILING.
-```
-
-The right answer to *"how long do we keep tickets?"* is almost never a single number — it's a two-track policy. Raw ticket bodies contain PII and must respect deletion requests on a DSR clock (typically 30 days under GDPR). De-identified aggregate analytics (resolution times, category counts) can persist indefinitely for product / ops insight.
-
-## Required structure in every support-retention answer
-
-1. **Two tracks.** Raw ticket body + attachments (PII): short retention with DSR honoring. Aggregate metrics (de-identified): long retention OK.
-2. **Consent-window check.** If consent was time-bound (e.g., "we'll keep your data for 12 months for support quality"), name the expiry and the deletion job that must run.
-3. **DSR readiness.** *"You must be able to honor a deletion request within [N] days. The system needs a query that finds every ticket + attachment + log line tied to one customer."*
-4. **Backup retention gotcha.** *"Backups also contain PII. Either purge on the same DSR clock or document that backups are inaccessible and rotate within [N] days."*
-
-## Default floors (cite, then qualify)
-
-| Class | Typical floor | Driver |
-|---|---|---|
-| Raw ticket body | 12-24 months from close | Consent window + DSR readiness |
-| Attachments with PII | 6-12 months | Higher leak risk → shorter |
-| Aggregate analytics (de-identified) | Indefinite | No PII linkage |
-| Quality-assurance recordings | 30-90 days | Consent typically narrow |
-
-Verify against the customer's privacy notice, regulatory regime, and contractual data-processing agreements before locking values.
-
-## See also
-
-- `skill:data-handling-judgment` — retention + DSR shape.
-- `skill:privacy-review` — regulatory-regime read.

package/.agent-src/rules/e2e-testing.md

@@ -1,19 +0,0 @@
----
-type: "auto"
-tier: "3"
-description: "Playwright E2E tests — locators, assertions, Page Objects, fixtures, CI, and flaky test prevention"
-source: package
-triggers:
-  - keyword: "playwright"
-  - keyword: "e2e"
-  - phrase: "page object"
-routes_to:
-  - "command:e2e-heal"
----
-
-# E2E Testing
-
-**Iron Law.** Playwright E2E: stable locators, no `waitForTimeout`, Page Objects for shared flows, fixtures over `beforeEach`.
-
-Body migrated to `command:e2e-heal` (per P4 of `road-to-kernel-and-router.md`).
-Trigger-set above activates this routing under the `balanced` and `full` profiles.

package/.agent-src/rules/no-unsolicited-rebase.md

@@ -1,107 +0,0 @@
----
-type: "auto"
-tier: "2a"
-alwaysApply: false
-description: "Working with git history — never rewrite, rebase, squash, fixup, or amend without explicit user request; shape is the user's call, not tidiness"
-source: package
-triggers:
-  - intent: "rebase the branch"
-  - intent: "squash commits"
-  - intent: "clean up commit history"
-  - intent: "fold this into the previous commit"
-  - keyword: "git rebase"
-  - keyword: "fixup"
-  - keyword: "--amend"
-  - keyword: "force-push"
-  - keyword: "squash-merge"
----
-
-# No Unsolicited Rebase
-
-## Iron Law
-
-```
-NEVER REBASE, SQUASH, FIXUP, OR AMEND PUBLISHED OR LOCAL HISTORY
-WITHOUT THE USER ASKING FOR IT THIS TURN.
-LINEAR HISTORY IS A PREFERENCE, NOT A DEFAULT.
-COMMIT-CHUNK ORDER IS NOT A CORRECTNESS GOAL.
-```
-
-Add the next commit on top. Never reorder, fold, drop, or rewrite earlier
-commits to make the log "look right".
-
-## Why this rule exists
-
-Interactive rebase + fixup loops generate disproportionate token cost on
-every iteration: re-running CI per replayed commit, resolving the same
-content conflict in three derived files (`.compression-hashes.json`,
-`router.json`, `.windsurfrules`), losing the working tree to a stash that
-silently re-introduces older state. A single conflict can burn the budget
-of an entire feature. The user pays for it. The "clean history" payoff is
-cosmetic; reviewers read the diff, not the log.
-
-## When rebase / amend / fixup IS allowed
-
-Exactly three:
-
-1. **User says so this turn** — "rebase onto main", "squash these two",
-   "amend that". This operation only, not a standing rule.
-2. **Standing instruction not yet revoked** — the user said earlier in
-   the conversation "always squash before pushing"; honor it.
-3. **Conflict resolution forced by `git pull --rebase`** — the user
-   already invoked the rebase via pull; finish it.
-
-Anything else — chunk-tidiness, "logical order", folding a follow-up fix
-into its parent — **forbidden**. The follow-up ships as its own commit
-(`fix: …`, `chore: …`).
-
-## Equivalents that are also forbidden by default
-
-- `git rebase -i` (interactive)
-- `git rebase --autosquash`
-- `git commit --fixup` / `--squash` (the helper that feeds the autosquash)
-- `git commit --amend` on already-pushed commits
-- `git push --force` / `--force-with-lease`
-- `git reset --hard` past unpushed work the user might want
-- Squash-merge of a PR via API or CLI when the user has not picked the
-  merge strategy
-- Cherry-pick rewriting that drops or reorders commits
-
-`--amend` on the *current local* commit before the first push is the
-narrow exception (treated as continuing to compose the commit, not
-rewriting history).
-
-## When you'd be tempted
-
-- "I want commit 3 to come before commit 2 because the topic flows better."
-  → don't. Reviewers read the PR diff.
-- "There are two `chore: regenerate` commits, ugly." → don't. They are
-  honest checkpoints.
-- "A linter caught an issue in commit 2 — let me fold the fix in."
-  → don't. Add `fix(scope): …` on top.
-- "I want to drop the WIP commit before pushing." → ask the user first.
-- "Squash-merge when I open the PR will clean it anyway." → also true,
-  also irrelevant — let the merge strategy do that work, not you.
-
-## Failure mode catalog
-
-- **Rebase-conflict cascade.** Interactive rebase replays N commits. Any
-  derived file (`.compression-hashes.json`, generated tool projections,
-  index/catalog) carries a hash per commit and conflicts on every replay.
-  Resolution time scales with N, not with the actual change.
-- **Stash-pop reverts work.** A `git stash` issued during rebase recovery
-  can re-introduce older edits that overwrite committed work after the
-  rebase finishes. Hard to spot in `git status` because the file shapes
-  match.
-- **Force-push during review.** Rewriting history on a branch with an
-  open PR invalidates review comments anchored to commits and forces a
-  re-review.
-
-## See also
-
-- [`scope-control`](scope-control.md) — git-ops permission gate ("rebase"
-  already named in the canonical list).
-- [`commit-policy`](commit-policy.md) — commits are the user's call;
-  rewriting them is a stronger version of the same restriction.
-- [`token-efficiency`](token-efficiency.md) — Iron Law on burning the
-  user's tokens for cosmetic gain.

package/.agent-src/rules/post-push-rewrite-discipline.md

@@ -1,70 +0,0 @@
----
-type: "auto"
-tier: "2a"
-alwaysApply: false
-description: "Git history after a push — squash/amend/rebase of pushed commits must pair with immediate re-push in same turn; stop on divergent state"
-source: package
-triggers:
-  - intent: "squash the pushed branch"
-  - intent: "clean up commits on the PR branch"
-  - intent: "tidy history after pushing"
-  - keyword: "git rebase -i"
-  - keyword: "--amend"
-  - keyword: "force-push"
-  - keyword: "--force-with-lease"
-  - phrase: "branch diverged"
-  - phrase: "pull --rebase failed"
-  - phrase: "ahead and behind"
-routes_to:
-  - "skill:git-workflow"
----
-
-# Post-Push Rewrite Discipline
-
-## Iron Law
-
-```
-ONCE PUSHED, A COMMIT IS PUBLISHED.
-ANY REWRITE OF PUSHED HISTORY MUST PAIR WITH AN IMMEDIATE RE-PUSH
-IN THE SAME TURN — OR DON'T REWRITE.
-NEVER END A SESSION WITH REWRITTEN-BUT-UNPUSHED LOCAL HISTORY.
-```
-
-## Two protective stops
-
-1. **Pre-rewrite stop.** Before any squash / amend / rebase on a
-   branch that is on origin: `git fetch && git rev-list --left-right
-   --count HEAD...@{u}`. If **either** side is non-zero — STOP and
-   route to `skill:git-workflow § Divergent-State Recovery`. A blind
-   `git pull --rebase` in this state is the documented failure mode.
-
-2. **Post-rewrite stop.** After the rewrite, push in the **same turn**
-   with `--force-with-lease=<branch>:<fetched-sha>` and verify
-   `git rev-parse origin/<branch>` equals `git rev-parse HEAD`.
-   If the push fails (hook, network, token budget) — fix the cause
-   and re-push **before** ending the session, committing new work,
-   or handing off.
-
-If either stop fires and resolution is not immediate → tag the state
-(`git tag local-rewritten-tip-<ISO-date>`) and hand control back to
-the user. Do not let a new session inherit a dirty divergence.
-
-## Why this rule exists
-
-A previous session squashed a pushed branch, the push hook failed at
-the token boundary, the session ended — and the next session saw
-local and origin pointing at different SHAs for the same logical work.
-A blind `git pull --rebase` cascaded into conflicts across every
-derived file (`.compression-hashes.json`, router projections). Recovery
-required forensic SHA-archaeology. This rule makes that sequence
-structurally impossible: rewrite without immediate push is forbidden.
-
-## See also
-
-- [`no-unsolicited-rebase`](no-unsolicited-rebase.md) — whether to
-  rewrite at all (this rule kicks in once rewriting is authorized).
-- [`skill:git-workflow`](../skills/git-workflow/SKILL.md) — Safe
-  Squash-After-Push protocol and Divergent-State Recovery decision
-  tree.
-- [`commit-policy`](commit-policy.md) — never rewrite or commit
-  without explicit authorization.