@event4u/agent-config 2.24.0 → 2.26.0

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.