familysync/.planning/quick/260613-dmw-exclude-gitea-workflow-config-changes-fr/260613-dmw-PLAN.md

---
phase: quick-260613-dmw
plan: 01
type: execute
wave: 1
depends_on: []
files_modified: [.gitea/workflows/ci.yml]
autonomous: true
requirements: []

must_haves:
  truths:
    - "A PR touching ONLY files under .gitea/** resolves code=false (heavy api/harness jobs skip, gate treats them as OK)"
    - "A PR touching .gitea/** AND app code/lockfile still resolves code=true (heavy jobs run)"
    - "ci.yml remains valid YAML and passes pnpm format:check"
  artifacts:
    - path: ".gitea/workflows/ci.yml"
      provides: "changes-job paths-filter with .gitea/** excluded from the code filter"
      contains: "!.gitea/**"
  key_links:
    - from: ".gitea/workflows/ci.yml changes.code filter"
      to: "api/harness job if: needs.changes.outputs.code == 'true'"
      via: "negation pattern ordered after positive yml/yaml globs"
      pattern: "!\\.gitea/\\*\\*"
---

<objective>
Exclude workflow-config changes (`.gitea/**`) from the CI `code` paths-filter so a PR that touches ONLY workflow/CI files is treated like a docs-only PR: the heavy `api` and `harness` jobs skip, while `fast-checks` (always runs; its `format:check` validates the workflow YAML) and `gate` still gate the PR.

Purpose: Workflow-only edits should not pay the multi-minute MariaDB + integration + Playwright harness cost. Per the project's tiered-gate rule, a CI-config edit does not need the full test harness — `fast-checks` + `gate` are sufficient gates for it.

Output: A one-line addition to the `changes` job's `dorny/paths-filter@v4` `code` filter in `.gitea/workflows/ci.yml`.
</objective>

<execution_context>
@$HOME/.claude/gsd-core/workflows/execute-plan.md
@$HOME/.claude/gsd-core/templates/summary.md
</execution_context>

<context>
@.planning/STATE.md
@.gitea/workflows/ci.yml
</context>

<tasks>

<task type="auto">
  <name>Task 1: Exclude .gitea/** from the CI code paths-filter</name>
  <files>.gitea/workflows/ci.yml</files>
  <action>
In the `changes` job's `dorny/paths-filter@v4` step (`id: filter`), add a single negation entry `- '!.gitea/**'` to the `code` filter list. Place it as the LAST entry of the `code` list — after every positive glob (`**/*.yaml`, `**/*.yml`, `apps/**`, `packages/**`, `pnpm-lock.yaml`, `Dockerfile`, `docker-compose*.yml`). Ordering is load-bearing: dorny/paths-filter evaluates patterns in sequence and a negation only overrides positive globs that precede it; the `**/*.yml`/`**/*.yaml` globs that currently make `.gitea/` workflow edits resolve `code=true` MUST appear before the negation.

Match the existing two-space list indentation and single-quoted-glob style used by the surrounding entries. Do NOT remove or reorder any existing positive glob. Do NOT touch the `fast-checks`, `api`, `harness`, `security`, or `gate` jobs, the `outputs.code` mapping, or which jobs `gate` aggregates in its `needs`. This negation is the only change to the file.

Net behavior after the edit:
- PR touching ONLY `.gitea/**` (e.g. editing this workflow): the yml/yaml positive match is overridden by the negation → `code=false` → `api`/`harness` carry their `if: ... code == 'true'` and skip → `gate`'s success-or-skipped loop accepts them.
- PR touching `.gitea/**` AND app code or lockfile (e.g. `apps/**`, `pnpm-lock.yaml`): the app-code positive glob still matches and is not under `.gitea/`, so the negation does not cancel it → `code=true` → heavy jobs run.
  </action>
  <verify>
    <automated>cd /home/luc/Projects/familysync &amp;&amp; awk '/^  fast-checks:/{exit} /code:/{f=1} f' .gitea/workflows/ci.yml | grep -nE "'!\.gitea/\*\*'|'\*\*/\*\.ya?ml'" &amp;&amp; python3 -c 'import sys,yaml; d=yaml.safe_load(open(".gitea/workflows/ci.yml")); code=d["jobs"]["changes"]["steps"][0]["with"]["filters"]; lines=[l.strip().lstrip("- ").strip("\x27\"") for l in code.splitlines() if l.strip().startswith("- ")]; neg=lines.index("!.gitea/**"); yml=max(i for i,p in enumerate(lines) if p in ("**/*.yml","**/*.yaml")); assert neg>yml, f"negation at {neg} must follow last yml/yaml glob at {yml}"; print("OK: .gitea/** negation present and ordered after yml/yaml globs")'</automated>
  </verify>
  <done>
`.gitea/workflows/ci.yml` parses as valid YAML; the `code` filter contains `!.gitea/**` positioned after the `**/*.yml`/`**/*.yaml` globs; no positive glob removed; only the `changes` job changed; `pnpm format:check` passes for the file.
  </done>
</task>

</tasks>

<verification>
1. YAML validity: `python3 -c 'import yaml; yaml.safe_load(open(".gitea/workflows/ci.yml"))'` exits 0.
2. Negation present and correctly ordered: the `code` list contains `!.gitea/**` as an entry that appears AFTER both `**/*.yml` and `**/*.yaml` (asserted by the Task 1 automated check).
3. Formatting: `pnpm format:check` passes (no Prettier diff on the workflow file).
4. Scope guard: `git diff --stat` shows ONLY `.gitea/workflows/ci.yml` changed, and `git diff .gitea/workflows/ci.yml` shows a single added line `- '!.gitea/**'` (no deletions, no other-job edits).
</verification>

<success_criteria>
- A workflow-only PR (touching only `.gitea/**`) resolves `code=false` → `api` + `harness` skip → `gate` passes via its success-or-skipped acceptance.
- A PR touching `.gitea/**` plus app code/lockfile resolves `code=true` → heavy jobs run.
- `fast-checks` and `gate` are unchanged and still gate every PR; `fast-checks` `format:check` continues to validate workflow YAML.
- No existing positive glob removed; no change to `fast-checks`, `api`, `harness`, `security`, or `gate`.
</success_criteria>

<output>
Create `.planning/quick/260613-dmw-exclude-gitea-workflow-config-changes-fr/260613-dmw-SUMMARY.md` when done.

Suggested commit message:
`ci: exclude .gitea/** from heavy-job paths-filter`

Body rationale: Workflow-only edits shouldn't pay for the multi-minute MariaDB/integration/harness suite. A negation `- '!.gitea/**'` (ordered after the yml/yaml globs) makes CI-config-only PRs resolve code=false so api/harness skip like docs; fast-checks (format:check still validates the workflow YAML) + gate continue to gate them. PRs that also touch app code/lockfile still resolve code=true and run the full suite.
</output>