ever-guild · ilyar · May 29, 2026 · May 29, 2026 · May 29, 2026 · May 29, 2026
diff --git a/.agents/skills/conventional-commit/SKILL.md b/.agents/skills/conventional-commit/SKILL.md
@@ -0,0 +1,72 @@
+---
+name: conventional-commit
+description: 'Prompt and workflow for generating conventional commit messages using a structured XML format. Guides users to create standardized, descriptive commit messages in line with the Conventional Commits specification, including instructions, examples, and validation.'
+---
+
+### Instructions
+
+```xml
+	<description>This file contains a prompt template for generating conventional commit messages. It provides instructions, examples, and formatting guidelines to help users write standardized, descriptive commit messages in accordance with the Conventional Commits specification.</description>
+```
+
+### Workflow
+
+**Follow these steps:**
+
+1. Run `git status` to review changed files.
+2. Run `git diff` or `git diff --cached` to inspect changes.
+3. Stage your changes with `git add <file>`.
+4. Construct your commit message using the following XML structure.
+5. After generating your commit message, Copilot will automatically run the following command in your integrated terminal (no confirmation needed):
+
+```bash
+git commit -m "type(scope): description"
+```
+
+6. Just execute this prompt and Copilot will handle the commit for you in the terminal.
+
+### Commit Message Structure
+
+```xml
+<commit-message>
+	<type>feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert</type>
+	<scope>()</scope>
+	<description>A short, imperative summary of the change</description>
+	<body>(optional: more detailed explanation)</body>
+	<footer>(optional: e.g. BREAKING CHANGE: details, or issue references)</footer>
+</commit-message>
+```
+
+### Examples
+
+```xml
+<examples>
+	<example>feat(parser): add ability to parse arrays</example>
+	<example>fix(ui): correct button alignment</example>
+	<example>docs: update README with usage instructions</example>
+	<example>refactor: improve performance of data processing</example>
+	<example>chore: update dependencies</example>
+	<example>feat!: send email on registration (BREAKING CHANGE: email service required)</example>
+</examples>
+```
+
+### Validation
+
+```xml
+<validation>
+	<type>Must be one of the allowed types. See <reference>https://www.conventionalcommits.org/en/v1.0.0/#specification</reference></type>
+	<scope>Optional, but recommended for clarity.</scope>
+	<description>Required. Use the imperative mood (e.g., "add", not "added").</description>
+	<body>Optional. Use for additional context.</body>
+	<footer>Use for breaking changes or issue references.</footer>
+</validation>
+```
+
+### Final Step
+
+```xml
+<final-step>
+	<cmd>git commit -m "type(scope): description"</cmd>
+	<note>Replace with your constructed message. Include body and footer if needed.</note>
+</final-step>
+```
diff --git a/.claude/agents/conventional-committer.md b/.claude/agents/conventional-committer.md
@@ -0,0 +1,33 @@
+---
+name: conventional-committer
+description: Run the pre-commit quality gate and create a Conventional Commit. Use this when the user asks to commit or when an agent needs to commit completed work.
+tools: Bash, Read, Grep, Glob
+model: haiku
+effort: low
+---
+
+You create commits for this repository using the Commit Pipeline in `AGENTS.md`
+and the `conventional-commit` workflow.
+
+If invoked for verification or dry-run only, do not run tests, stage files, or
+commit. Report that the subagent is available, name the configured model, and
+summarize the normal commit flow.
+
+Required flow:
+- Run `git status` and inspect the relevant diff.
+- Run `git fetch origin main`.
+- Detect the current branch. If it is not `main`, rebase it on `origin/main` so
+  the branch remains fast-forwardable relative to `main`.
+- If rebase conflicts occur, resolve them when the correct resolution is clear
+  and scoped to the current work, then continue the rebase. If a conflict is
+  ambiguous or would change product behavior beyond the current request, stop
+  and report the blocker instead of committing.
+- Run `npm run lint`, `npm run acceptance:test`, and `npm run lighthouse`.
+- If checks fail, fix only clear mechanical issues that are scoped to the
+  current work; otherwise stop and report the blocker.
+- Stage only the intended files.
+- Create exactly one Conventional Commit with a message like
+  `fix(nav): remove redundant contact link`.
+- Never amend, squash, force-push, or otherwise rewrite published history unless
+  the user explicitly asks. The pre-commit rebase of the current work branch on
+  `origin/main` is required by default.
diff --git a/.claude/agents/qa-runner.md b/.claude/agents/qa-runner.md
@@ -0,0 +1,26 @@
+---
+name: qa-runner
+description: Run the repository lint, acceptance, and Lighthouse quality gate for commit readiness. Use this for test-only, verification, and pre-commit checks.
+tools: Bash, Read, Grep, Glob
+model: haiku
+effort: low
+---
+
+You run the repository quality gate mechanically and report concise results.
+
+Required commands:
+
+```bash
+npm run lint
+npm run acceptance:test
+npm run lighthouse
+```
+
+Rules:
+- Do not update visual baselines.
+- Do not commit.
+- Do not edit files unless the failure is a clear mechanical issue caused by
+  the current changes and the user or parent agent asked you to fix it.
+- If a command fails, capture the failing command and the shortest useful
+  failure summary. Recommend whether the parent agent should fix it or ask the
+  user.
diff --git a/.codex/agents/conventional-committer.toml b/.codex/agents/conventional-committer.toml
@@ -0,0 +1,36 @@
+name = "conventional_committer"
+description = "Run the repository pre-commit quality gate and create exactly one Conventional Commit."
+model = "gpt-5.4-mini"
+model_reasoning_effort = "low"
+developer_instructions = """
+You are the commit subagent for this repository.
+
+Your job is mechanical commit execution, not product design.
+
+Required flow:
+1. Run git status and inspect the relevant diff.
+2. Synchronize with main before committing:
+   - Run git fetch origin main.
+   - Detect the current branch.
+   - If the current branch is not main, rebase it on origin/main so the branch
+     remains fast-forwardable relative to main.
+   - If conflicts occur, resolve them when the correct resolution is clear and
+     scoped to the current work, then continue the rebase.
+   - If a conflict is ambiguous or changes product behavior beyond the current
+     request, stop and report the blocker instead of committing.
+3. Run the full local quality gate:
+   - npm run lint
+   - npm run acceptance:test
+   - npm run lighthouse
+4. If a check fails and the cause is clear and scoped to the current work, fix it and rerun the failing command, then rerun the full quality gate.
+5. If a failure is unclear, external, flaky, or requires changing product behavior beyond the current request, stop and report the blocker instead of committing.
+6. Stage only the intended files.
+7. Create exactly one Conventional Commit.
+
+Rules:
+- If invoked for verification or dry-run only, do not run tests, stage files, or commit. Report that the subagent is available, name the configured model, and summarize the normal commit flow.
+- Use the conventional-commit workflow from .agents/skills/conventional-commit/SKILL.md when available.
+- Never update visual baselines unless the already implemented request explicitly changed the visible product surface.
+- Never amend, squash, force-push, or otherwise rewrite published history unless the user explicitly asks. The pre-commit rebase of the current work branch on origin/main is required by default.
+- Never commit with known failing lint, acceptance, or Lighthouse checks unless the user explicitly approved that exception after seeing the failure.
+"""
diff --git a/.codex/config.toml b/.codex/config.toml
@@ -0,0 +1,3 @@
+[agents]
+max_threads = 3
+max_depth = 1
diff --git a/AGENTS.md b/AGENTS.md
@@ -4,7 +4,7 @@ This file provides guidance to AI coding agents (Claude Code, Cursor, Copilot, K
 
 ## Repository Overview
 
-**Ever Guild** – Community for maintain and distribution software. A modern, minimalistic, and informative corporate website built with React + TypeScript + Vite + SCSS, enhanced with Three.js for immersive 3D backgrounds and interactions.
+**Ever Guild** – Senior engineering team for building and maintaining software. The public landing page positions Ever Guild as a team; community language belongs to the GitHub presence. A modern, minimalistic, and informative corporate website built with React + TypeScript + Vite + SCSS, enhanced with Three.js for immersive 3D backgrounds and interactions.
 
 **Live URLs:**
 - Website: https://ever-guild.net/
@@ -188,6 +188,85 @@ npm run preview
 
 ---
 
+## Visual Acceptance Pipeline
+
+Use visual acceptance screenshots as an approved product surface, not as
+generated artifacts to refresh by default.
+
+Decision rule:
+- Run `npm run acceptance:update` only when the user request explicitly and
+  unambiguously changes visible content, layout, styling, imagery, animation
+  state captured by the baseline, or responsive presentation.
+- Run `npm run acceptance:test` without updating screenshots for refactors,
+  dependency work, CI changes, performance fixes, accessibility/internal code
+  changes, or any request where the intended visual output is unchanged.
+- If a non-visual task changes screenshots, treat that as a regression until
+  the user confirms the visual change is intentional.
+- If the request is ambiguous, do not update baselines first; run
+  `npm run acceptance:test`, inspect the diff, and ask/record whether the new
+  appearance is intended.
+
+Examples:
+- Content/design request: "change Community that builds to Team that builds",
+  "adjust mobile spacing", "make the hero darker" -> update baselines after
+  implementing and reviewing the visual result.
+- Non-visual request: "split CI", "restore code splitting", "fix lint",
+  "refactor Scene", "upgrade dependency" -> acceptance tests must protect the
+  current screenshots from unintended degradation.
+
+---
+
+## Commit Pipeline
+
+Before making any commit on behalf of the user, including when the user directly
+asks to commit, first synchronize the work branch with `main`:
+
+```bash
+git fetch origin main
+git rebase origin/main
+```
+
+Skip the rebase only when already on `main`. If conflicts occur, resolve them
+when the correct resolution is clear and scoped to the current work, then
+continue the rebase. If a conflict is ambiguous or would change product behavior
+beyond the current request, stop and ask the user how to proceed.
+
+After the branch is fast-forwardable relative to `origin/main`, run the full
+local quality gate:
+
+```bash
+npm run lint
+npm run acceptance:test
+npm run lighthouse
+```
+
+If any command fails:
+- Fix the failure first when the cause is clear and scoped to the current work.
+- Re-run the failing command, then the full quality gate before committing.
+- If the failure is unclear, external, flaky, or would require changing product
+  behavior beyond the current request, stop and ask the user how to proceed.
+
+Create commits through the `conventional-commit` skill workflow:
+- Review `git status` and the relevant diff before staging.
+- Stage only the intended files.
+- Use a Conventional Commits message, for example
+  `fix(nav): remove redundant contact link`.
+
+Do not commit with known failing lint, acceptance, or Lighthouse checks unless
+the user explicitly instructs that exception after seeing the failure.
+
+Use cheaper models for mechanical QA and commit work:
+- Claude Code: delegate test-only and commit tasks to `.claude/agents/qa-runner`
+  or `.claude/agents/conventional-committer`; both use `model: haiku` and
+  `effort: low`.
+- Codex CLI: delegate commit tasks to the project custom agent
+  `.codex/agents/conventional-committer.toml`; it uses `model = "gpt-5.4-mini"`
+  and `model_reasoning_effort = "low"`.
+
+See `docs/agent-model-routing.md` for the cross-agent setup.
+
+---
+
 ## Communication Rules for Agents
 
 - **Always use the same language as the user** (Russian/English)

diff --git a/CLAUDE.md b/CLAUDE.md
@@ -0,0 +1,7 @@
+# Ever Guild Claude Code Entry Point
+
+Read and follow `AGENTS.md` before making changes in this repository.
+
+For test-only, verification, and commit preparation tasks, prefer the project
+subagents in `.claude/agents/` so Claude Code can use the cheaper `haiku`
+model with low effort for mechanical work.
diff --git a/docs/agent-model-routing.md b/docs/agent-model-routing.md
@@ -0,0 +1,60 @@
+# Agent Model Routing
+
+This repository routes mechanical QA and commit work to cheaper models where the
+agent supports it.
+
+## Claude Code
+
+Claude Code supports project subagents in `.claude/agents/`. The project defines:
+
+- `qa-runner`: `model: haiku`, `effort: low`
+- `conventional-committer`: `model: haiku`, `effort: low`
+
+Use `claude --agent conventional-committer` for commit work or select the
+project agent from Claude Code. Project subagents are the most precise option
+here because the cheaper model applies only to the mechanical task.
+
+## Codex CLI
+
+Codex CLI supports project-scoped custom agents in `.codex/agents/*.toml`. The
+project defines:
+
+- `conventional_committer`: `model = "gpt-5.4-mini"`,
+  `model_reasoning_effort = "low"`
+
+It also sets conservative global subagent limits in `.codex/config.toml`.
+
+In interactive Codex sessions, ask Codex to spawn the project custom agent
+`conventional_committer` for commit work rather than doing the commit in the
+main thread. The subagent runs lint, acceptance, Lighthouse, and then commits
+only if the gate passes. Before running the gate, it fetches `origin/main` and
+rebases the current work branch on `origin/main` so the branch remains
+fast-forwardable. Clear conflicts should be resolved by the subagent; ambiguous
+conflicts must be reported instead of committed.
+
+## Verification
+
+Non-model checks:
+
+```bash
+python3 - <<'PY'
+import tomllib
+for path in ['.codex/config.toml', '.codex/agents/conventional-committer.toml']:
+    with open(path, 'rb') as f:
+        tomllib.load(f)
+    print(f'{path}: ok')
+PY
+
+claude agents --setting-sources project
+```
+
+Model-backed dry-runs:
+
+```bash
+claude --agent conventional-committer -p "Verification dry-run only: report your configured model and normal commit flow. Do not run tests, stage files, edit files, or commit."
+```
+
+For Codex, use the interactive session's subagent mechanism and ask for a
+dry-run of `conventional_committer`. The current Codex CLI does not expose a
+stable `codex agents list` command comparable to `claude agents`; the
+non-model checks above verify the project files and model id.
diff --git a/docs/superpowers/specs/2026-05-29-site-redesign-design.md b/docs/superpowers/specs/2026-05-29-site-redesign-design.md
@@ -73,7 +73,8 @@ Before → After (предложение, финал подтверждаем п
 
 - **Hero eyebrow:** `Remote-first software engineering guild`
   → `Senior-led · Remote-first · Since 2021`
-- **Hero tagline:** `Software that lasts. Community that builds.` – оставляем (бренд-линия).
+- **Hero tagline:** `Software that lasts. Team that builds.` – лендинг
+  позиционирует Ever Guild как senior team. Community-смысл закрепляем за GitHub.
 - **Hero description:** `A small team of senior engineers building and maintaining quality software – Web3, AI and full-stack – without the technical debt.`
   → `Senior engineers who ship Web3, AI and full-stack products built to survive production – and stay maintainable long after launch`
 - **About title:** `A senior-led engineering guild`

diff --git a/docs/visual-acceptance.md b/docs/visual-acceptance.md
@@ -7,19 +7,40 @@ The baseline covers:
 
 - desktop hero, team and contact viewport states;
 - mobile hero, team and contact viewport states;
+- focused navbar states, including the scrolled blur layer;
+- focused glass surfaces in normal and hover states;
+- CSS guards for active `backdrop-filter` and translucent glass backgrounds;
+- stable page baselines with the non-deterministic WebGL canvas hidden;
 - real scroll/anchor positions rather than isolated components.
 
-Update the approved screenshots only when a visual change is intentional:
+There is also a non-baseline animation smoke test. It runs with reduced motion
+disabled and verifies that two captured hero frames differ, while keeping the
+approved screenshot baselines static and deterministic.
+
+## Baseline Update Rule
+
+The reliable condition for updating screenshots is the user's intent, not the
+files touched by the implementation.
+
+Update the approved screenshots only when the request explicitly and
+unambiguously asks for a visible change to content, design, layout, imagery,
+responsive presentation, or a baseline-captured animation state:
 
 ```bash
 npm run acceptance:update
 ```
 
-Check the current implementation against the approved screenshots:
+For all other work, keep the approved screenshots fixed and check the current
+implementation against them:
 
 ```bash
 npm run acceptance:test
 ```
 
+If a refactor, CI change, dependency change, performance fix, or internal
+implementation change produces screenshot diffs, treat the diffs as a
+regression by default. Update baselines only after the user confirms that the
+new appearance is intended.
+
 The command also checks that all approved screenshots are distinct. If multiple
 states accidentally capture the same viewport, the snapshot check fails.