colorsense 0.1.0__tar.gz

colorsense-0.1.0/.gitignore

@@ -0,0 +1,223 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer,
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+.claude/
+
+# Local-only orchestration notes (not part of the published project)
+ORCHESTRATOR_INSTRUCTIONS.md

colorsense-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Cass
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

colorsense-0.1.0/PKG-INFO

@@ -0,0 +1,239 @@
+Metadata-Version: 2.4
+Name: colorsense
+Version: 0.1.0
+Summary: Extract the rendered color palette from any website as a typed result.
+Project-URL: Homepage, https://github.com/cassidyhhaas/colorsense
+Project-URL: Repository, https://github.com/cassidyhhaas/colorsense
+Project-URL: Issues, https://github.com/cassidyhhaas/colorsense/issues
+Author: Cass
+License-Expression: MIT
+License-File: LICENSE
+Keywords: color,css,design-tokens,palette,playwright,web
+Classifier: Development Status :: 4 - Beta
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Topic :: Multimedia :: Graphics
+Classifier: Topic :: Software Development :: Libraries :: Python Modules
+Classifier: Typing :: Typed
+Requires-Python: >=3.12
+Requires-Dist: coloraide>=4
+Requires-Dist: httpx>=0.27
+Requires-Dist: numpy>=1.26
+Requires-Dist: pillow>=10
+Requires-Dist: playwright>=1.40
+Requires-Dist: pydantic>=2
+Requires-Dist: pyyaml>=6
+Description-Content-Type: text/markdown
+
+# colorsense
+
+Extract the rendered color palette from any website and return a structured, typed result
+intended for downstream consumers — including AI models — that need to understand a site's
+color identity (for example, to derive their own theme-matched colors).
+
+colorsense renders a page under light (and, on request, dark) color schemes, harvests its
+design tokens and computed element colors, classifies them into a 60/30/10 palette, and
+reconciles what the site *declares* (CSS custom properties) against what it actually *uses*.
+It returns the palette roles and scoring; producing concrete color choices for a given
+widget is left to the consumer.
+
+## Install
+
+```bash
+pip install colorsense
+playwright install chromium
+```
+
+Rendering uses a headless Chromium via Playwright. The browser binary is **not** a Python
+package, so it cannot be pulled in as a pip dependency — run `playwright install chromium`
+once after installing to download it (and `playwright install-deps chromium` on Linux to
+pull the OS libraries Chromium needs).
+
+For development from a checkout, use [uv](https://docs.astral.sh/uv/):
+
+```bash
+uv sync
+uv run playwright install chromium
+```
+
+## Quickstart
+
+`analyze` is **async-native** (it renders with Playwright's async API and renders the
+themes concurrently), so await it from an event loop. The result's `themes` map each color
+scheme to its **60/30/10 palette** — five roles, each with ranked, scored candidate colors:
+
+```python
+import asyncio
+from colorsense import analyze, PaletteRole
+
+result = asyncio.run(analyze("https://example.com"))
+
+for theme, palette in result.themes.items():
+    # mapping always contains every role; () when none was detected
+    candidates = palette.roles.mapping[PaletteRole.primary]
+    if candidates:
+        primary = candidates[0]               # top candidate for the role
+        print(theme, primary.color.hex, primary.probability)
+```
+
+Each role — `primary`, `secondary`, `accent`, `neutral_light`, `neutral_dark` — maps to a
+probability-ranked tuple of candidates. Take `[0]` for the best pick.
+
+Inside an async application (e.g. a FastAPI `async def` endpoint) just
+`result = await analyze(url)` directly — no threadpool hop required.
+
+## The result
+
+`analyze` returns a fully typed `AnalysisResult` (a Pydantic model —
+`result.model_dump_json()` round-trips). The fields most consumers use:
+
+**`themes`** — the payload: each `Theme` mapped to its reconciled palette `roles`. You walk
+`palette.roles.mapping[role]` to a tuple of candidates, where each candidate carries:
+
+- `color` — a `Color`: an sRGB `hex` string plus cached **OKLCH** coordinates (`lightness`,
+  `chroma`, `hue`) of the composited color, and the source `alpha`. `hex` is what you paint
+  with; the OKLCH coordinates make it easy to derive your own theme-matched colors — sort by
+  perceptual lightness, build accessible tints/shades, or compute contrast — without
+  re-parsing the hex.
+- `probability` — confidence this color fills the role (candidates within a role rank by it).
+- `area` — the fraction of page area the color covers, i.e. its 60/30/10 dominance.
+
+Sites that ignore `prefers-color-scheme` (near-identical light/dark renders) collapse to a
+single reported theme.
+
+**`fit_score`** — how well the measured palette matches the canonical 60/30/10 split, in
+`[0, 1]`. A quick quality signal for the analysis as a whole.
+
+**`status_colors`** — success/error/warning colors detected and deliberately **kept out** of
+the palette, so a red error banner doesn't masquerade as a brand accent.
+
+**`metadata`** — a typed `RunMetadata`: which themes were requested versus actually analyzed,
+whether the run collapsed to a single theme, and the fetch policy in effect. Useful for
+logging and for detecting the single-theme collapse.
+
+## Options
+
+```python
+import asyncio
+from colorsense import analyze, LIGHT_AND_DARK, PolitenessPolicy, Viewport
+
+result = asyncio.run(
+    analyze(
+        "https://example.com",
+        viewport=Viewport(width=1440, height=900, device_scale_factor=2.0),
+        themes=LIGHT_AND_DARK,                          # opt in to dark mode; default is light only
+        politeness=PolitenessPolicy(min_interval=2.0),  # see "Fetching responsibly" below
+        config_path="my_palette_config.yaml",           # advanced; see "Custom tuning" below
+    )
+)
+```
+
+By default `analyze` renders **light mode only** — most sites have no dark mode, and a
+second theme roughly doubles the render cost. Pass `themes=LIGHT_AND_DARK` (equivalently
+`themes=(Theme.light, Theme.dark)`) to also analyze dark mode; near-identical light/dark
+renders are collapsed back to a single reported theme. A custom `viewport` captures a
+different layout (e.g. mobile), which can yield a different palette.
+
+## Fetching responsibly: politeness, authorization & security
+
+colorsense fetches and renders a third-party page. **Authorization is the consumer's
+responsibility** — the library provides *mechanism, not policy*. `PolitenessPolicy`
+(in [`net/politeness.py`](src/colorsense/net/politeness.py)) gives you the controls:
+
+- a configurable, identifiable **User-Agent**;
+- a **`robots.txt` gate**, on by default (`respect_robots=True`) — a disallow raises
+  `RobotsDisallowedError`;
+- a per-host **rate limiter** (`min_interval` seconds between same-host fetches);
+- a simple URL→render **cache**.
+
+Choose your posture by where colorsense runs:
+
+- **Server-side / batch** (you analyze sites you operate or are authorized to crawl): keep
+  `respect_robots=True`, set a conservative `min_interval`, and use an identifiable
+  User-Agent so site operators can contact you.
+
+  ```python
+  policy = PolitenessPolicy(
+      user_agent="MyApp/1.0 (+https://myapp.example/bot)",
+      min_interval=2.0,
+  )
+  ```
+
+- **Embedded / on-demand** (a user pastes a URL into your product to theme a widget): you
+  may legitimately analyze a page the user is entitled to view. You still own the decision
+  to fetch — gate it on your own authorization, terms of service, and rate limits *before*
+  calling `analyze`. Disabling `respect_robots` is an explicit, accountable choice, not a
+  default.
+
+colorsense never decides whether a fetch is permitted; it only makes it easy to fetch
+considerately once you have decided.
+
+**Security (SSRF + local-file reads).** `analyze` fetches and renders whatever URL it is
+given, so passing **untrusted** URLs exposes a server-side request forgery and local-file-read
+surface. `file://` URLs read arbitrary local files (intentional, for the test fixtures), and
+`http(s)://` URLs can reach internal hosts and cloud metadata endpoints (e.g.
+`169.254.169.254`, `localhost`). This is by design — the politeness controls above gate
+*network* schemes for robots/rate-limiting, but nothing validates the destination host. If
+you accept user-supplied URLs, validate the scheme and host **before** calling `analyze`:
+allowlist public hosts, and reject `file://` and private / link-local IP ranges. As above,
+this is the consumer's responsibility — the library provides mechanism, not policy.
+
+## Advanced
+
+### Design-token auditing
+
+Beyond the palette, `analyze` reports what the site's CSS **declares** versus what it
+actually **renders** — useful for auditing a design system you own:
+
+- **`tokens`** — the declared design tokens (CSS custom properties) with their inferred
+  semantic roles (e.g. `--accent-500` read as `brand_accent`), for the primary theme.
+- **`divergence`** — discrepancies between intent and usage: brand colors **declared but
+  unused** in the render, and prominent rendered colors that are **used but undeclared**.
+
+```python
+for item in result.divergence:
+    print(item.note, item.color.hex)     # e.g. "declared '--brand' unused in render"
+```
+
+### Custom tuning
+
+[`palette_config.yaml`](src/colorsense/data/palette_config.yaml) **ships bundled with the
+package** and is loaded automatically. It is the single source of truth for the **token
+vocabulary** (CSS custom-property names → semantic roles → 60/30/10 palette-role priors) and
+the **component-classifier** weights (how rendered elements are scored into headers, cards,
+CTAs, …). The weights are calibrated starting points, not ground truth.
+
+To tune them, copy the bundled file, edit your copy, and pass its path as `config_path=` to
+`analyze` (or load it with `load_config`). To inspect the defaults programmatically:
+
+```python
+from colorsense import load_default_config
+
+config = load_default_config()
+```
+
+`config_path=` tunes the token vocabulary and the component classifier. The usage-side
+role-scoring weights are documented in-code constants in
+[`palette/roles.py`](src/colorsense/palette/roles.py) (e.g. `W_AREA`, `SOFTMAX_T`,
+`TARGET_SPLIT`), not part of the YAML.
+
+## Development
+
+```bash
+uv run ruff check .
+uv run ruff format --check .
+uv run mypy src
+uv run pytest
+```
+
+Tests are network-free: live-page work runs against saved fixture HTML under
+`tests/fixtures/` served via `file://`. Integration tests in
+[`tests/test_integration_sites.py`](tests/test_integration_sites.py) pin golden snapshots of
+the analysis; regenerate them after an intentional change with:
+
+```bash
+UPDATE_GOLDEN=1 uv run pytest tests/test_integration_sites.py
+```

colorsense-0.1.0/README.md

@@ -0,0 +1,209 @@
+# colorsense
+
+Extract the rendered color palette from any website and return a structured, typed result
+intended for downstream consumers — including AI models — that need to understand a site's
+color identity (for example, to derive their own theme-matched colors).
+
+colorsense renders a page under light (and, on request, dark) color schemes, harvests its
+design tokens and computed element colors, classifies them into a 60/30/10 palette, and
+reconciles what the site *declares* (CSS custom properties) against what it actually *uses*.
+It returns the palette roles and scoring; producing concrete color choices for a given
+widget is left to the consumer.
+
+## Install
+
+```bash
+pip install colorsense
+playwright install chromium
+```
+
+Rendering uses a headless Chromium via Playwright. The browser binary is **not** a Python
+package, so it cannot be pulled in as a pip dependency — run `playwright install chromium`
+once after installing to download it (and `playwright install-deps chromium` on Linux to
+pull the OS libraries Chromium needs).
+
+For development from a checkout, use [uv](https://docs.astral.sh/uv/):
+
+```bash
+uv sync
+uv run playwright install chromium
+```
+
+## Quickstart
+
+`analyze` is **async-native** (it renders with Playwright's async API and renders the
+themes concurrently), so await it from an event loop. The result's `themes` map each color
+scheme to its **60/30/10 palette** — five roles, each with ranked, scored candidate colors:
+
+```python
+import asyncio
+from colorsense import analyze, PaletteRole
+
+result = asyncio.run(analyze("https://example.com"))
+
+for theme, palette in result.themes.items():
+    # mapping always contains every role; () when none was detected
+    candidates = palette.roles.mapping[PaletteRole.primary]
+    if candidates:
+        primary = candidates[0]               # top candidate for the role
+        print(theme, primary.color.hex, primary.probability)
+```
+
+Each role — `primary`, `secondary`, `accent`, `neutral_light`, `neutral_dark` — maps to a
+probability-ranked tuple of candidates. Take `[0]` for the best pick.
+
+Inside an async application (e.g. a FastAPI `async def` endpoint) just
+`result = await analyze(url)` directly — no threadpool hop required.
+
+## The result
+
+`analyze` returns a fully typed `AnalysisResult` (a Pydantic model —
+`result.model_dump_json()` round-trips). The fields most consumers use:
+
+**`themes`** — the payload: each `Theme` mapped to its reconciled palette `roles`. You walk
+`palette.roles.mapping[role]` to a tuple of candidates, where each candidate carries:
+
+- `color` — a `Color`: an sRGB `hex` string plus cached **OKLCH** coordinates (`lightness`,
+  `chroma`, `hue`) of the composited color, and the source `alpha`. `hex` is what you paint
+  with; the OKLCH coordinates make it easy to derive your own theme-matched colors — sort by
+  perceptual lightness, build accessible tints/shades, or compute contrast — without
+  re-parsing the hex.
+- `probability` — confidence this color fills the role (candidates within a role rank by it).
+- `area` — the fraction of page area the color covers, i.e. its 60/30/10 dominance.
+
+Sites that ignore `prefers-color-scheme` (near-identical light/dark renders) collapse to a
+single reported theme.
+
+**`fit_score`** — how well the measured palette matches the canonical 60/30/10 split, in
+`[0, 1]`. A quick quality signal for the analysis as a whole.
+
+**`status_colors`** — success/error/warning colors detected and deliberately **kept out** of
+the palette, so a red error banner doesn't masquerade as a brand accent.
+
+**`metadata`** — a typed `RunMetadata`: which themes were requested versus actually analyzed,
+whether the run collapsed to a single theme, and the fetch policy in effect. Useful for
+logging and for detecting the single-theme collapse.
+
+## Options
+
+```python
+import asyncio
+from colorsense import analyze, LIGHT_AND_DARK, PolitenessPolicy, Viewport
+
+result = asyncio.run(
+    analyze(
+        "https://example.com",
+        viewport=Viewport(width=1440, height=900, device_scale_factor=2.0),
+        themes=LIGHT_AND_DARK,                          # opt in to dark mode; default is light only
+        politeness=PolitenessPolicy(min_interval=2.0),  # see "Fetching responsibly" below
+        config_path="my_palette_config.yaml",           # advanced; see "Custom tuning" below
+    )
+)
+```
+
+By default `analyze` renders **light mode only** — most sites have no dark mode, and a
+second theme roughly doubles the render cost. Pass `themes=LIGHT_AND_DARK` (equivalently
+`themes=(Theme.light, Theme.dark)`) to also analyze dark mode; near-identical light/dark
+renders are collapsed back to a single reported theme. A custom `viewport` captures a
+different layout (e.g. mobile), which can yield a different palette.
+
+## Fetching responsibly: politeness, authorization & security
+
+colorsense fetches and renders a third-party page. **Authorization is the consumer's
+responsibility** — the library provides *mechanism, not policy*. `PolitenessPolicy`
+(in [`net/politeness.py`](src/colorsense/net/politeness.py)) gives you the controls:
+
+- a configurable, identifiable **User-Agent**;
+- a **`robots.txt` gate**, on by default (`respect_robots=True`) — a disallow raises
+  `RobotsDisallowedError`;
+- a per-host **rate limiter** (`min_interval` seconds between same-host fetches);
+- a simple URL→render **cache**.
+
+Choose your posture by where colorsense runs:
+
+- **Server-side / batch** (you analyze sites you operate or are authorized to crawl): keep
+  `respect_robots=True`, set a conservative `min_interval`, and use an identifiable
+  User-Agent so site operators can contact you.
+
+  ```python
+  policy = PolitenessPolicy(
+      user_agent="MyApp/1.0 (+https://myapp.example/bot)",
+      min_interval=2.0,
+  )
+  ```
+
+- **Embedded / on-demand** (a user pastes a URL into your product to theme a widget): you
+  may legitimately analyze a page the user is entitled to view. You still own the decision
+  to fetch — gate it on your own authorization, terms of service, and rate limits *before*
+  calling `analyze`. Disabling `respect_robots` is an explicit, accountable choice, not a
+  default.
+
+colorsense never decides whether a fetch is permitted; it only makes it easy to fetch
+considerately once you have decided.
+
+**Security (SSRF + local-file reads).** `analyze` fetches and renders whatever URL it is
+given, so passing **untrusted** URLs exposes a server-side request forgery and local-file-read
+surface. `file://` URLs read arbitrary local files (intentional, for the test fixtures), and
+`http(s)://` URLs can reach internal hosts and cloud metadata endpoints (e.g.
+`169.254.169.254`, `localhost`). This is by design — the politeness controls above gate
+*network* schemes for robots/rate-limiting, but nothing validates the destination host. If
+you accept user-supplied URLs, validate the scheme and host **before** calling `analyze`:
+allowlist public hosts, and reject `file://` and private / link-local IP ranges. As above,
+this is the consumer's responsibility — the library provides mechanism, not policy.
+
+## Advanced
+
+### Design-token auditing
+
+Beyond the palette, `analyze` reports what the site's CSS **declares** versus what it
+actually **renders** — useful for auditing a design system you own:
+
+- **`tokens`** — the declared design tokens (CSS custom properties) with their inferred
+  semantic roles (e.g. `--accent-500` read as `brand_accent`), for the primary theme.
+- **`divergence`** — discrepancies between intent and usage: brand colors **declared but
+  unused** in the render, and prominent rendered colors that are **used but undeclared**.
+
+```python
+for item in result.divergence:
+    print(item.note, item.color.hex)     # e.g. "declared '--brand' unused in render"
+```
+
+### Custom tuning
+
+[`palette_config.yaml`](src/colorsense/data/palette_config.yaml) **ships bundled with the
+package** and is loaded automatically. It is the single source of truth for the **token
+vocabulary** (CSS custom-property names → semantic roles → 60/30/10 palette-role priors) and
+the **component-classifier** weights (how rendered elements are scored into headers, cards,
+CTAs, …). The weights are calibrated starting points, not ground truth.
+
+To tune them, copy the bundled file, edit your copy, and pass its path as `config_path=` to
+`analyze` (or load it with `load_config`). To inspect the defaults programmatically:
+
+```python
+from colorsense import load_default_config
+
+config = load_default_config()
+```
+
+`config_path=` tunes the token vocabulary and the component classifier. The usage-side
+role-scoring weights are documented in-code constants in
+[`palette/roles.py`](src/colorsense/palette/roles.py) (e.g. `W_AREA`, `SOFTMAX_T`,
+`TARGET_SPLIT`), not part of the YAML.
+
+## Development
+
+```bash
+uv run ruff check .
+uv run ruff format --check .
+uv run mypy src
+uv run pytest
+```
+
+Tests are network-free: live-page work runs against saved fixture HTML under
+`tests/fixtures/` served via `file://`. Integration tests in
+[`tests/test_integration_sites.py`](tests/test_integration_sites.py) pin golden snapshots of
+the analysis; regenerate them after an intentional change with:
+
+```bash
+UPDATE_GOLDEN=1 uv run pytest tests/test_integration_sites.py
+```