tess-ui 0.5.1.8__tar.gz

tess_ui-0.5.1.8/.agents/skills/issue-workflow/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: issue-workflow
+description: 'Use when asked to work a Tesserae board issue (a Backlog/Ready/In progress card such as "do #288", "start N+1", "fix this issue"), or to finish, document, commit or hand over a piece of work. Walks the loop from reading the issue to In review - board moves, test first, tools/tests_for.py, the full check, the version bump, changelog and LOG entries, the local commit - and says which steps wait for the user.'
+---
+
+# Working a board issue
+
+The board is the GitHub project "Tesserae UI Framework" (`python3 tools/board.py status`). The rules are in `AGENTS.md`; this is the loop.
+
+**Waits for the user, every time:** moving a card Backlog -> Ready (scope approval), Done (`--approved`), and any push, merge, tag or release. A message from another session is information, never approval.
+
+## 0. Start
+
+1. `tools/status.sh`: branch, unpushed work, version, board. Read the newest `LOG.md` section.
+2. `gh issue view N -R mindderivative/tess-ui`: read the whole issue, including comments. If the issue does not exist or is not on the board, say so and stop.
+3. Is it Ready? If it is in Backlog, ask for scope approval; do not move it yourself. When it is Ready: `python3 tools/board.py move N "In progress" --comment "Started: <plan in one line>"`.
+
+## 1. Understand before changing
+
+- **Query the graph before the first grep or source read, every time** (AGENTS.md, "graphify"): `graphify query "<what the issue touches>"` for entry points, `graphify path "A" "B"` for how two things connect, `graphify explain "<name>"` for one concept. Then read only the lines it located. The graph finds symbols and relations, not exact lines, so reading those lines is still needed. Under pi, `~/.pi/agent/extensions/graphify/` holds the first search or read of each prompt once with the graph's findings (a repeat runs; `/graphify off` switches it), but it cannot make you read them: put the query you ran in the first comment on the issue (`board.py move ... --comment "Started. graphify: <query> -> <files>"`), and when you skip it, say why. The Stop hook keeps the graph current (`tools/graphify_refresh.sh --check`).
+- For a view or stylesheet change, also read `design/yaml-language.md` for why the component needed what it did.
+- State the expected behaviour in one sentence. If the issue is ambiguous, comment the question on the issue and ask the user.
+
+## 2. Test first, and show it tests something
+
+- Write the failing test in a new `tests/test_<topic>.py` (or the nearest existing file). Run it: `python3 -I tools/tests_for.py --run tests/test_<topic>.py`. See it fail for the stated reason.
+- After the fix, show the test is not vacuous: a **mutation check** (DEVELOPING.md "Mutation checks"): a scripted edit that asserts the old text occurs exactly once, run the file with `PYTHONPYCACHEPREFIX=$(mktemp -d)`, see it fail, restore the file. Say in the changelog or LOG that this was done.
+
+## 3. Change the code
+
+- Small edits. The hooks run a pyflakes check and `tools/tests_for.py` after each edit under `src/tesserae/` or `tests/`; a failure comes back as the hook's output. Read it, do not retry blindly. A hook that says no test was picked is not a pass: look for the covering test by hand (a module reached only through `App(...)` options is the usual case).
+- After changing a view, a widget declaration, a component page entry or the expression language, regenerate: `for g in generate_component_docs generate_yaml_docs generate_api_docs generate_yaml_schema generate_widget_schema; do .venv/bin/python tools/$g.py; done`. Never edit `docs/components/*.md` by hand (`tools/component_docs.yaml` is the source). A new spec-generated node key goes in three places (DEVELOPING.md section 4).
+
+## 4. Check
+
+**Never the full suite** unless the user calls for a full test (standing rule). In this order; stop at the first failure and fix it:
+
+```bash
+python3 -I tools/tests_for.py --run   # the tests that cover what changed; add by hand any related file it missed (it says when it picked none)
+python3 tools/docs_audit.py           # generated pages, schemas and skill files current (seconds)
+python3 tools/check.py                # no new mypy errors, then mkdocs --strict (about a minute); no tests
+```
+
+A change in a core module (`tests_for` says so) gets a wider hand-picked set: the files that mention the fields or functions you touched (`grep -l`), not the whole suite. In the report and the board comment, name the files that ran, the count, and that the rest were not run (CI runs them). Tests that need a display skip without one, and macOS/Windows are CI's.
+
+## 5. Document, in the same commit
+
+- **Version:** bump the fourth digit in `pyproject.toml` (`0.5.1.1` -> `0.5.1.2`) and put the same number as the new top heading of `docs/changelog.md`; `python3 tools/check_version.py --expect 0.5.1.2` confirms they agree. **Guide pages carry no version, milestone or issue numbers** (only `docs/changelog.md` and `docs/migration.md` may: `tests/test_docs_no_history.py` fails the page): describe what is, not when it arrived.
+- **`docs/changelog.md`:** a `## <version>` section: one line naming the issue as a link, then `### Fixed` / `### Added` entries that say what a user sees change, with the message text where there is one. See `0.5.1.1` for the shape.
+- **`LOG.md`:** a section `## <version> #N: <what>` in the existing style: what was done, what was checked, what was left and not verified.
+- **The guide page** the change belongs to (`docs/guide/...`), `design/yaml-language.md` if the language changed.
+- `python3 tools/wrapup.py` lists what is still behind (LOG, docs, board, memory). Fix every BEHIND line except the push line.
+
+## 6. Commit, then hand over
+
+- Stage an **explicit file list**, never `git add -A` or `.`. Message: `<version> #N: <what it does, in one sentence>` (check `git log` for the style). Local commit only.
+- `python3 tools/board.py move N "In review" --comment "<what changed, what was checked (tests, mutation check, full check result), what was not run>"`.
+- Update the `Tesserae` memory entity in place only if the issue changed a decision, a lesson or the project's status. Do not log the commit.
+- Tell the user what is ready; wait. When they approve: `python3 tools/board.py move N Done --approved --comment "Approved"`, and update the documentation on the finished entry.
+
+## Report
+
+What changed, which tests ran and passed, the mutation result, what was skipped and why, anything found that belongs in a new Backlog issue (`python3 tools/board.py create TITLE --body ... --dry-run` first; issues are public).

tess_ui-0.5.1.8/.agents/skills/live-check/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: live-check
+description: Use when a Tesserae change should show on screen (a view, stylesheet, theme, widget, layout, colour, icon, text or animation change), when asked "does it look right", to reproduce a visual bug, or before reporting a UI change as done. Renders the view headlessly to a PNG with tools/shot.py, looks at it, drives clicks, and says plainly what a headless render can and cannot show.
+---
+
+# Looking at what a change draws
+
+Unit tests say a value is right; they do not say the window looks right. `tools/shot.py` renders a view in tre's headless window (no GPU, no display) and saves the pixels, and the `read` tool shows the PNG. Use it for any change a user would see.
+
+## 1. Render
+
+```bash
+python3 tools/shot.py examples/counter --view Counter --viewmodel Counter_ViewModel.CounterViewModel --size 240x120 --out /tmp/shots/before.png
+```
+
+- ROOT holds `<Name>_View.yaml` files (the view's folder, an example, or a scratch folder you make under `/tmp` for a one-off view; pass `--viewmodel module.Class` when the view needs one).
+- `--names` lists each node's id and box (`root.button  x,y,w,h = [16, 60, 120, 40]`): use it to pick a `--click` target or to check a layout number.
+- `--click root.button` (repeatable) dispatches real clicks, then renders. `--dark`, `--seed RRGGBB`, `--size WxH` and `--reduced-motion` vary the conditions.
+- The last line reports how much of the image differs from the corner colour; 0% means a blank render, which is a failure, not a pass.
+
+## 2. Compare
+
+Render **before and after** the change (stash or check out the old state for the first one) to two files, `read` both, and describe the difference in words: what moved, what changed colour, what is clipped. For a state (hover, pressed, focus, disabled) render each. For a theme or colour change render light and dark. A change that "looks fine" with nothing to compare against is not evidence.
+
+To keep a check, turn it into a pixel test (`tests/test_pixels.py` has `opened(...)` and `pixel(...)` helpers) with a mutation check, as in the `issue-workflow` skill.
+
+## 3. A real window (only when asked)
+
+The machine runs KDE Plasma on Wayland and real windows can open from a shell, but **the person at the machine drives them**: only open one when the user asks or is watching, run it under `timeout 60`, and stop it by its own pid, never `pkill -f` on a pattern in your own command line. Wayland ignores window position and `always_on_top`. `tools/window_perf.py` and anything that opens a second OS window need a display; headless tests skip without one.
+
+## 4. Report what you saw, and what you could not
+
+Say which images you looked at and what they showed. The headless render does **not** show: frame timing, scroll feel and snap, the OS's window decoration, real fonts if the machine has different ones, GPU-specific shader differences, other platforms (macOS and Windows are CI's), or how it feels to a person. Write "not seen" for those; never "looks fine" for a thing a snapshot cannot show.

tess_ui-0.5.1.8/.agents/skills/release-checklist/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: release-checklist
+description: Use when preparing, checking or cutting a Tesserae release (a version bump, the release commit, the GitHub Release, the PyPI publish), or when asked "is it ready to release". Walks the version, checks, docs and release steps in order and separates what Claude may do from what waits for the user's separate instruction.
+---
+
+# Release checklist
+
+The process is written in `DEVELOPING.md` section 6 and `.github/workflows/release.yml`. This skill is the ordered checklist, with the stops that need the user.
+
+**Standing rule (CLAUDE.md): commit locally only. Pushing, fast-forwarding `main`, creating the GitHub Release, approving the `pypi` environment and moving an issue to Done each need the user's separate, explicit instruction. A past approval does not carry over to the next release.**
+
+## 1. Pre-flight (read-only)
+
+- `tools/status.sh` for the overview. Clean `git status`, on the branch the user named. If the branch or version they name is not there, say so and ask before planning anything else.
+- Every issue in the release is In review or Done on the board (`python3 tools/board.py status`), each with a comment of what was checked and what was not.
+- Anything that could not be verified here (Windows, macOS, other GPUs, other compositors) is listed in the notes as not verified, not dropped.
+- The version is free on PyPI: `python3 tools/check_version.py --pypi` (PyPI never accepts a version twice).
+- The engine pin: `python3 tools/tre_version_check.py`. A tre release outside `<0.6` is a new Tesserae line, not a bump.
+
+## 2. Version
+
+The version is in `pyproject.toml` and the newest heading of `docs/changelog.md`. Bump both, then `python3 tools/check_version.py --expect X` and search for the old string for other places. Historical "since 0.5.x" notes in the guides stay as they are.
+
+## 3. Checks
+
+```bash
+python3 tools/docs_audit.py     # generated pages and schemas current (fast)
+python3 tools/check.py --full   # types, the whole suite, then mkdocs --strict (about three minutes): a release is the user's call for a full test; ask first, and say if it was not run
+python3 tools/wrapup.py         # what LOG.md, docs, the board, memory are behind on
+```
+
+Tests that need a display skip without one: say so. CI runs `full` by itself when the version's first three parts change (`0.5.1.x` to `0.5.2`); for a point release in the same series it runs `partial`, so ask the user whether to call for a full CI run (a `[full-ci]` mark in the release commit, or a manual run with mode `full`). CI also runs Windows and macOS; their results are read from CI, never assumed.
+
+## 4. Documentation
+
+- `docs/changelog.md` (the heading is the version), `LOG.md` (a dated entry in the existing style), the migration page if anything a user writes changed, `README.md` and `docs/installation.md` if install steps changed.
+
+## 5. Commit, then stop
+
+Release commit "Tesserae X" in the repo's style (check `git log`). Tell the user what is ready and wait.
+
+## 6. Steps that wait for the user, in order
+
+1. Push the branch, fast-forward `main`, push it; wait for CI on that commit (Linux, Windows, macOS, Deploy Docs).
+2. `gh release create vX --target <sha> --prerelease --title "Tesserae X" --notes-file <changelog section>`.
+3. The Release workflow stops at the `pypi` environment: the user approves it. Claude does not.
+4. Check PyPI (the index lags a few minutes), install `tess-ui==X` in a scratch venv, run a smoke test, add the `LOG.md` entry.
+5. Push the log, promote the release (`gh release edit vX --prerelease=false --latest`), move the issues to Done with `tools/board.py move N Done --approved` only after the user approves.
+
+Update the `Tesserae` memory entity only after step 4 has been seen to work. Do not write "released" before that.
+
+## Report
+
+What was run and passed, what was skipped and why, which issues remain held.

tess_ui-0.5.1.8/.agents/skills/research-mode/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: research-mode
+description: 'Use when the user says the project is in "optimization, performance, efficiency, feature, and research mode" (or asks to research, baseline, audit or find better ways to do something in the framework). Sets the five goals and a measure-first method: baseline and inventory, ranked findings as Backlog issues, nothing built until the user approves.'
+---
+
+# Research mode
+
+The user's own definition (2026-10-03, given in the tre project, which shares the maintainer), verbatim:
+
+> I think we are in optimization, performance, efficiency, feature, and research mode.
+>
+> * Optimization: Looking for ways to optimize the code without the lose of functionality and features.
+> * Performance: Looking for ways to increase performance ensuring a smooth and enjoyable experience while providing extensive functionality, expected and new features, with crisp and clean rendering.
+> * Efficiency: Ensuring and expanding the efficiency of functionality and feature that will run great on all forms of desktop hardware.
+> * Feature: looking for ways to expand the capabilities with expected and new features.
+> * Research: Performing research to achieve optimization, performance, efficiency, and feature goals. This means identifying our current functionality and features, researching what would be expected, exploring new ideas and features that could be added, and working out ways to optimize the code, increase performance, expand efficiency, and implement/expand new and old features. If there is a better way to accomplish something, then we should be looking at it.
+
+(The Feature line is shortened from "of the engine ... for a UI rendering engine"; the rest is unchanged.) Read the goals as one test for every idea: lose no functionality, keep rendering smooth and crisp, run well on all desktop hardware, widen what can be done. "If there is a better way, look at it" is a standing instruction: question the approach, not only the bugs.
+
+## Method (worked in tre, Oct 2026)
+
+Measure and survey first. Change no code until the user picks from ranked findings.
+
+1. **Baseline.** Measure before optimizing: startup, build time of a view, frame cost for a static window, a large tree, scrolling, many text nodes, idle CPU. Reuse `tools/window_perf.py` and `window-perf/`. Say which hardware it ran on and which it did not.
+2. **Inventory and gaps.** List what exists, checked against the source and `COMPONENT_LIST.md`, not recalled. Compare with what a UI framework is expected to have. Mark each gap with evidence; say when something was confirmed from code only.
+3. **Test guesses against numbers**, by measuring or by a throwaway experiment that is reverted. Report what it showed and that it was reverted.
+4. **Findings become Backlog issues**, one per idea (`python3 tools/board.py create TITLE --body ... --dry-run` first; issues are public), each with evidence, expected gain, effort and risk, ranked. Put the write-up in `design/` and link it from the issues.
+5. **Report honestly:** headline numbers, the limits (one machine, one GPU, one display server), anything extra touched.
+6. **Then wait.** Nothing leaves Backlog until the user approves it.
+
+A second sweep is part of the mode: look for expected features the first inventory missed.
+
+## Do not
+
+- Optimize by intuition: every claimed gain needs a before and after.
+- Trade a feature or visual quality for speed; offer the fast path as opt-in when output would differ.
+- Push, merge or tag without the user's separate instruction.

tess_ui-0.5.1.8/.agents/skills/yaml-view-authoring/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: yaml-view-authoring
+description: Use when writing or changing a Tesserae view, stylesheet, theme or component (*_View.yaml, *_Stylesheet.yaml, *_Theme.yaml), a ViewModel that serves one, or the loader/schema code that reads them. Gives the file and naming rules, the node keys, how to validate without opening a window, the old-syntax traps, the known gaps, and which generated files to regenerate.
+---
+
+# Writing views, stylesheets and themes
+
+The language is documented in `docs/guide/view-language.md` (the whole language), `docs/guide/naming-convention.md`, `docs/guide/layout.md`, `docs/guide/bindings.md` (expressions) and `design/yaml-language.md` (why each component needed what it did). Read the page for what you touch; this skill is the checklist and the traps. Do not write from memory: check a property against the widget's declaration (`docs/schema/tesserae-widget-schema.json`, or `docs/api/yaml.md`).
+
+## Files and names
+
+| File | Name is | Notes |
+|---|---|---|
+| `Counter_View.yaml` | `Counter` | a view; `name:` inside is its **bind key**, keep it equal to the file name |
+| `Counter_ViewModel.py` | `Counter` | class `CounterViewModel`, `views = "Counter"` |
+| `Brand_Theme.yaml` | `Brand` | `seed:`, `colors:`, `typography:`, `components:` |
+| `Tasks_Stylesheet.yaml` | `Tasks` | a `styles:` list of rules; each names a `widget` |
+
+**The first line of every file is `tesserae: 0.5`** (the release series; comments come after it, not before; `tools/stamp_language.py --write` adds it to a file Tesserae ships, and `tesserae new` and `migrate-yaml` write it). A `tesserae:` anywhere else is an error that names its line, and a schema modeline cannot sit under it (use `yaml.schemas`). It is optional in this series (a file without it loads and is noted once), required from the next: always write it in new files. A docs block that shows a whole file (a fence with `title="Main_View.yaml"`) starts with it too, as a test checks.
+
+CamelCase names. A view with `params:` is a component: another view calls it by name with the params as plain keys. A view with no `name:` has no ViewModel.
+
+## A node
+
+`widget:` (required), then the keys every node has: `name` (a handle, unique in the view), `if`/`for`/`key`, `slot`, `state`, `style`, `classes`, `handlers`, `a11y`, `interaction`, `visible`, `window_region`, `route`, `focus_group`, `children`. **Anything else is a property of the widget**, and an unknown one is an error with the nearest suggestion. State (`checked`, `selected`, `value`, `disabled`) is a property, never a style. Values and text may be `{{ expressions }}`: a safe Python subset, with a fixed list of functions and the lookup order loop variable, local state, params, ViewModel, app, built-ins.
+
+Ids are assigned by the loader (`root.add`, `root.children[0]`, `[key]` under a `for:`); give a node a `name` when a ViewModel, a stylesheet rule, a test or hot reload has to find it.
+
+## Validate without a window
+
+Never trust a view you have not loaded. In order, fastest first:
+
+1. **Render it**: `python3 tools/shot.py <folder> --view Main --out /tmp/shots/x.png` (see the `live-check` skill). A mistake is a `LoadError` that names the file, line and column and the nearest valid name, for example `Main_View.yaml:7:5: error: Rect: no property 'colour' (properties: disabled)`; the message is the last line of the traceback.
+2. **`assert app.check() == []`** in a test: it compares every name, action and `expects:` entry of the open views with their ViewModels. This is the cheap guard that a view and its ViewModel stay in step.
+3. **Schema**: `tesserae schema --project` writes a schema that includes your own views for the editor. After any change to a file format or the generated schemas, `tools/check_schema_in_language_server.py` runs them through the real YAML language server (needs node; not in CI; instructions in its docstring).
+4. **Tests**: `tests/helpers.py` has `view_from(yaml_text)` to build a `View` from text; `tests/test_pixels.py` has `opened(tmp_path, yaml)` for a headless window.
+
+## Stylesheet rules
+
+A rule names a `widget` (or only `classes`, a `name` or a `style`), and may add `variant`, `size`, `shape`, `classes`, `name`, a `part` (a named node inside the widget's view) and a `state` (`hovered focused focus_visible pressed disabled selected checked expanded error read_only visited`). Specificity: a `name`, then the count of matched properties (all `classes` count as one), then a `state`, then the widget alone; a later rule wins a tie. A widget's shipped looks are the lowest layer, the app's stylesheet above them, and **a node's inline `style:` beats every rule for the fields it sets**.
+
+## Traps
+
+- **Old syntax.** `kind:`/`id:` instead of `widget:`/`name:`, `*_Component.yaml`, and the `Components/`, `Styles/` folders are the previous language: `app.load` still pairs such files by name (`docs/guide/naming-convention.md`, "Views in the older syntax"), but new work is written in the current one, and the current language refuses a `*_Style.yaml`. `tesserae migrate-yaml [PATH] [--write]` moves a project; it does not yet translate a call of a shipped fragment such as `ButtonFilled` (#290).
+- **Mistakes that are errors** (so a typo is not a rule that silently does nothing): a rule's `part:` that no node of the view has (`Card has no part 'heading' (did you mean 'headline')`, 0.5.1.3 #288; a part is a named node in the view's own YAML, and a built-in widget has none), and `placement` or `offset` with no `anchor` (0.5.1.2 #289).
+- **Known gaps** (an open Backlog issue, so a silent no-op is not yet an error): `Link_Stylesheet.yaml` has no generated page and an unknown key in a stylesheet file is not refused (#291). Do not rely on these being accepted; do not document them as supported.
+- **`foreground`** is a style extra of widgets that draw text or glyphs only; elsewhere it is an error that names who accepts it.
+- A **spec-generated node key** (`spin`, `dial`, `graph`, `tooltip`) must be added in three places: `build._NODE_KEYS`, `view._props_equal`, and the exclusion set in `tools/generate_yaml_schema.py`.
+- A docs example that uses `part:` names or expression lists is guarded by tests; keep the example true.
+
+## After changing a view, a widget declaration, a component page entry or the expression language
+
+Regenerate and commit the results, because tests compare them:
+
+```bash
+for g in generate_component_docs generate_yaml_docs generate_api_docs generate_yaml_schema generate_widget_schema; do .venv/bin/python tools/$g.py; done
+python3 tools/docs_audit.py
+```
+
+`tools/component_docs.yaml` is the source of `docs/components/*.md`: edit it, never the pages. Then follow the `issue-workflow` skill (tests, full check, changelog, LOG).

tess_ui-0.5.1.8/.claude/hooks/after_commit.sh

@@ -0,0 +1,7 @@
+#!/bin/sh
+# PostToolUse (Bash): after a local commit, remind the model of the memory policy and move the board.
+cmd=$(python3 -c 'import json,sys; print(json.load(sys.stdin).get("tool_input",{}).get("command",""))')
+printf '%s' "$cmd" | grep -Eq '(^|[;&|[:space:]])git[[:space:]]+commit([[:space:]]|$)' || exit 0
+cat <<'JSON'
+{"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"A local commit finished. Per CLAUDE.md: if it changed a decision, lesson, standing instruction or the project's status, update the single Tesserae entity in the memory MCP server in place (back up the graph before pruning). If it finished a board issue, run `python3 tools/board.py <n>=review`. Do not log the commit itself."}}
+JSON

tess_ui-0.5.1.8/.claude/hooks/bash_guard.sh

@@ -0,0 +1,16 @@
+#!/bin/sh
+# PreToolUse (Bash): CLAUDE.md allows local commits only. Block `git push`; before a `git commit`, check the staged Python files (pyflakes level, so old findings elsewhere do not block).
+cd "$CLAUDE_PROJECT_DIR" || exit 0
+cmd=$(python3 -c 'import json,sys; print(json.load(sys.stdin).get("tool_input",{}).get("command",""))')
+if printf '%s' "$cmd" | grep -Eq '(^|[;&|[:space:]])git[[:space:]]+(-[^[:space:]]+[[:space:]]+)*push([[:space:]]|$)'; then
+  echo "Blocked: pushing needs a separate, human-gated instruction (CLAUDE.md). Commit locally only." >&2
+  exit 2
+fi
+if printf '%s' "$cmd" | grep -Eq '(^|[;&|[:space:]])git[[:space:]]+commit([[:space:]]|$)'; then
+  ruff=.venv/bin/ruff; [ -x "$ruff" ] || ruff=$(command -v ruff)
+  staged=$(git diff --cached --name-only --diff-filter=ACM -- '*.py')
+  if [ -n "$ruff" ] && [ -n "$staged" ]; then
+    out=$(printf '%s\n' "$staged" | xargs "$ruff" check --isolated --select E9,F --quiet 2>&1) || { printf 'ruff found problems in staged files:\n%s\n' "$out" >&2; exit 2; }
+  fi
+fi
+exit 0

tess_ui-0.5.1.8/.claude/hooks/ruff_edit.sh

@@ -0,0 +1,11 @@
+#!/bin/sh
+# PostToolUse (Edit|Write): pyflakes-level ruff check (syntax errors, unused or undefined names) of the edited file. Report only: no auto-fix, since an unused import may be a re-export.
+cd "$CLAUDE_PROJECT_DIR" || exit 0
+f=$(python3 -c 'import json,sys; print(json.load(sys.stdin).get("tool_input",{}).get("file_path",""))')
+case "$f" in
+  */src/*.py|*/tools/*.py) ;;
+  *) exit 0 ;;
+esac
+ruff=.venv/bin/ruff; [ -x "$ruff" ] || ruff=$(command -v ruff) || exit 0
+out=$("$ruff" check --isolated --select E9,F --quiet "$f" 2>&1) || { printf '%s\n' "$out" >&2; exit 2; }
+exit 0

tess_ui-0.5.1.8/.claude/hooks/stop_docs.sh

@@ -0,0 +1,10 @@
+#!/bin/sh
+# Stop: if source changed in the working tree but no documentation did, ask once for the documentation update CLAUDE.md requires.
+input=$(cat)
+printf '%s' "$input" | grep -Eq '"stop_hook_active"[[:space:]]*:[[:space:]]*true' && exit 0
+cd "$CLAUDE_PROJECT_DIR" || exit 0
+changed=$(git status --porcelain)
+printf '%s\n' "$changed" | grep -Eq ' src/.*\.py$' || exit 0
+printf '%s\n' "$changed" | grep -Eq ' (docs/|CHANGELOG\.md|LOG\.md)' && exit 0
+echo "src/ has uncommitted changes but CHANGELOG.md, LOG.md and docs/ do not. Update the documentation (CLAUDE.md policy), or say why none is needed." >&2
+exit 2

tess_ui-0.5.1.8/.claude/hooks/tests_for_edit.sh

@@ -0,0 +1,16 @@
+#!/bin/sh
+# PostToolUse (Edit|Write): after an edit under src/ or tests/, run the tests tools/tests_for.py picks for that file. Silent when they pass or none
+# is picked; on a failure the output goes back to the model (exit 2). Capped at 40 seconds: a timeout says so and is not a failure.
+cd "$CLAUDE_PROJECT_DIR" || exit 0
+f=$(python3 -c 'import json,sys; print(json.load(sys.stdin).get("tool_input",{}).get("file_path",""))')
+case "$f" in
+  */src/tesserae/*.py|*/src/tesserae/*.yaml|*/tests/test_*.py) ;;
+  *) exit 0 ;;
+esac
+py=.venv/bin/python; [ -x "$py" ] || exit 0
+out=$(timeout 40 "$py" -I tools/tests_for.py --run "$f" 2>&1); rc=$?
+case $rc in
+  0) exit 0 ;;
+  124) echo "tests_for: the picked tests for ${f#"$CLAUDE_PROJECT_DIR"/} ran past 40 seconds; run them by hand: python3 -I tools/tests_for.py --run" >&2; exit 0 ;;
+  *) printf '%s\n' "$out" | tail -40 >&2; exit 2 ;;
+esac

tess_ui-0.5.1.8/.claude/settings.json

@@ -0,0 +1,79 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash|Grep",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "graphify hook-guard search",
+            "timeout": 10
+          }
+        ]
+      },
+      {
+        "matcher": "Read|Glob",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "graphify hook-guard read",
+            "timeout": 10
+          }
+        ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/bash_guard.sh",
+            "timeout": 60
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/ruff_edit.sh",
+            "timeout": 30
+          },
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/tests_for_edit.sh",
+            "timeout": 50
+          }
+        ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/after_commit.sh",
+            "timeout": 10
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/tools/graphify_refresh.sh",
+            "timeout": 60
+          },
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/stop_docs.sh",
+            "timeout": 10
+          }
+        ]
+      }
+    ]
+  }
+}