django-brickwork 1.0.0rc1__tar.gz

django_brickwork-1.0.0rc1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Nigel Copley
+
+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.

django_brickwork-1.0.0rc1/NOTICE

@@ -0,0 +1,62 @@
+django-brickwork
+Copyright (c) 2026 Nigel Copley
+
+This product is licensed under the MIT License (see LICENSE).
+
+It includes third-party material under the terms below. These notices cover the
+vendored icon artwork seeded into the brickwork icon registry
+(src/brickwork/icons/vendor/). The icon *names* are brickwork's own versioned
+public contract; the vendored artwork is a pinned, swappable implementation
+detail behind those names.
+
+--------------------------------------------------------------------------------
+Lucide  (https://lucide.dev)
+--------------------------------------------------------------------------------
+
+The curated icon subset in src/brickwork/icons/vendor/lucide/ is taken from the
+`lucide-static` package (v1.28.0) and is used under the ISC License.
+
+  ISC License
+
+  Copyright (c) 2020, Lucide Contributors
+
+  Permission to use, copy, modify, and/or distribute this software for any
+  purpose with or without fee is hereby granted, provided that the above
+  copyright notice and this permission notice appear in all copies.
+
+  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH
+  REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
+  AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
+  INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
+  LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
+  OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+  PERFORMANCE OF THIS SOFTWARE.
+
+--------------------------------------------------------------------------------
+Feather  (https://feathericons.com)
+--------------------------------------------------------------------------------
+
+A subset of the Lucide icons above derive from Feather, which is distributed
+under the MIT License. That subset is therefore additionally covered by:
+
+  The MIT License (MIT)
+
+  Copyright (c) 2013-2023 Cole Bemis
+
+  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.

django_brickwork-1.0.0rc1/PKG-INFO

@@ -0,0 +1,193 @@
+Metadata-Version: 2.4
+Name: django-brickwork
+Version: 1.0.0rc1
+Summary: Brand-agnostic, app-facing professional UI substrate for server-rendered Django (Tailwind 4, Alpine 3, HTMX 2). Accessible by construction; not a Django-admin skin.
+Author: Nigel Copley
+License-Expression: MIT
+Project-URL: Homepage, https://github.com/icvoss/django-brickwork
+Project-URL: Documentation, https://github.com/icvoss/django-brickwork
+Project-URL: Changelog, https://github.com/icvoss/django-brickwork/blob/main/CHANGELOG.md
+Project-URL: Issue Tracker, https://github.com/icvoss/django-brickwork/issues
+Project-URL: Source Code, https://github.com/icvoss/django-brickwork
+Keywords: django,ui,design-system,tailwind,alpine,htmx,accessibility,wcag,components
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Web Environment
+Classifier: Framework :: Django
+Classifier: Framework :: Django :: 6.0
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Topic :: Software Development :: User Interfaces
+Requires-Python: >=3.12
+Description-Content-Type: text/markdown
+License-File: LICENSE
+License-File: NOTICE
+Requires-Dist: Django>=6.0
+Provides-Extra: htmx
+Requires-Dist: django-htmx>=1.28; extra == "htmx"
+Provides-Extra: dev
+Requires-Dist: pytest>=8.0; extra == "dev"
+Requires-Dist: pytest-django>=4.8; extra == "dev"
+Requires-Dist: pytest-cov>=5.0; extra == "dev"
+Requires-Dist: django-htmx>=1.28; extra == "dev"
+Requires-Dist: ruff>=0.5.0; extra == "dev"
+Requires-Dist: mypy>=1.10; extra == "dev"
+Dynamic: license-file
+
+# brickwork
+
+A brand-agnostic, app-facing professional UI substrate for server-rendered
+Django, on the ecosystem stack: Tailwind 4 (CSS-first), Alpine 3, HTMX 2,
+Django 6.0. It provides the application shell, navigation and active-route
+resolution, an accessible form-field renderer, and interaction primitives
+(modal, toast, dropdown, combobox, tabs, disclosure) wrapped behind stable
+Django components.
+
+**This is not a Django-admin skin.** Its value is the professional baseline:
+WCAG 2.2 AA as a *tested* guarantee (axe-core in CI, not a claim), RTL via
+logical properties, a real themeable dark-mode system, and four composable
+theme axes (brand x theme x density x direction). Applications provide data,
+permissions and business behaviour; the substrate provides structure,
+presentation and interaction conventions.
+
+> Status: **0.16.0, graduating to public PyPI.** The five semver-governed
+> public-API contracts (token, template, navigation, interaction, JavaScript)
+> are live, and every component passes two hard gates: is it accessible
+> (axe-core WCAG 2.2 AA in CI) and is it beautiful by default. The surface is
+> complete: the application shell and nav, the beautiful-by-default token system
+> (elevation, state overlays, type roles, motion, borders, with fine colours
+> derived live from a small load-bearing brand set via `color-mix()`), the
+> interaction set (modal, toast, dropdown, combobox, tabs, disclosure, tooltip,
+> slide-over), forms with the whole-form renderer and the HTMX 422 loop, the
+> data table with sortable and selectable modes, the feedback and input-chrome
+> primitives, the wizard/stepper, and a machine-readable token contract with a
+> per-tenant brand-CSS emitter. The design of record is the spec and brief in
+> the icvoss/oss umbrella:
+> - Spec: `docs/specs/django-brickwork/` (the five versioned public-API contracts).
+> - Design + branding + integration: `docs/DESIGN.md`, `docs/BRANDING.md`,
+>   `docs/INTEGRATION.md`, `docs/ADOPTION.md`.
+> - Changelog: `CHANGELOG.md` (0.1.0 through 0.16.0).
+
+## Documentation
+
+- [docs/DESIGN.md](docs/DESIGN.md): the canonical token reference; every
+  `--bw-*` name, default value, and derivation rule.
+- [docs/BRANDING.md](docs/BRANDING.md): how a consuming app brands brickwork
+  (the load-bearing token minimum, dark mode, the four axes, the fg-on-accent
+  contrast trap, and dynamic per-tenant / per-user theming recipes).
+- [docs/INTEGRATION.md](docs/INTEGRATION.md): the greenfield integration
+  cookbook, the seams a consuming app wires end to end (settings and static, nav
+  config, context processor, a worked HTMX 422 form, the chrome/body boundary).
+- [docs/ADOPTION.md](docs/ADOPTION.md): the strangle guide for migrating an
+  existing app onto brickwork cluster by cluster (multi-host, asset coexistence,
+  the htmx floor).
+- [frontend/README.md](frontend/README.md): the in-repo build that compiles
+  the shipped static assets.
+
+## Install
+
+```
+pip install django-brickwork        # from pypi.icvoss.com (private index)
+```
+
+```python
+INSTALLED_APPS = [
+    "brickwork",
+    # ...
+]
+```
+
+The compiled CSS and JS ship inside the package and are referenced with plain
+`{% static %}`; no build-tool dependency (django-vite / django-tailwind) is
+imposed on consumers. Consumers provide their own Alpine 3 +
+`@alpinejs/focus` (and optionally htmx 2) via their own frontend build; brickwork
+registers behaviour onto the host Alpine instance and never calls
+`Alpine.start()`.
+
+### htmx floor: htmx >= 2.0
+
+brickwork's interaction contracts (the HTMX 422 form-swap loop, toast delivery
+via `hx-swap-oob`, modal dismissal via the `HX-Trigger: bw:modal:close` response
+header, combobox server filtering) are built and CI-gated on **htmx >= 2.0**
+only. htmx 1.9 is out of contract (BR-BW-HTMX-010): htmx 2 changed default
+response handling in ways the 422 loop relies on, and the interaction suites only
+ever exercise htmx 2. A brownfield app on htmx 1.9 should upgrade htmx to 2.x as a
+prerequisite before adopting brickwork's interaction primitives; see
+[docs/ADOPTION.md](docs/ADOPTION.md).
+
+## Contracts
+
+brickwork's public API is five versioned contracts (see the spec): **token**,
+**template**, **navigation**, **interaction (HTMX)**, and **JavaScript
+(Alpine)**. Template block names, HTMX target IDs, Alpine component names,
+event names and token names are semver-governed.
+
+## Usage
+
+### Tags vs includes
+
+Some components are consumed as **template tags**, others via `{% include %}`.
+This is deliberate: a component that carries logic (variant validation, a11y
+enforcement, icon resolution) ships as a tag so that logic is not duplicated at
+every call site; a purely structural component is an include the consumer fills
+with context.
+
+- **Tags** (load the library first): `{% bw_icon %}`, `{% bw_button %}`,
+  `{% bw_badge %}`, `{% bw_alert %}`, `{% bw_nav %}`, `{% bw_field_widget %}`.
+
+  ```django
+  {% load brickwork_components brickwork_icons brickwork_nav %}
+  {% bw_button label="Save" variant="primary" %}
+  {% bw_badge label="New" variant="info" %}
+  ```
+
+  The `_button.html` / `_badge.html` / `_alert.html` template files exist but are
+  the tags' own render targets, **not** a consumer-facing `{% include %}` API.
+  Call the tag, not the partial.
+
+- **Includes** (structure you fill with context): `_page_header.html`,
+  `_data_table.html`, `_pagination.html`, `_empty_state.html`,
+  `_filter_bar.html`, `_spinner.html`, and the form partials `forms/_field.html`
+  / `forms/_form_errors.html`.
+
+  ```django
+  {% include "brickwork/components/_data_table.html" with table_id="gadgets" columns=columns rows=rows %}
+  ```
+
+### Icons: decorative or labelled, always
+
+`{% bw_icon %}` **requires** exactly one of `decorative=True` or `label="..."`,
+and raises `TemplateSyntaxError` if given neither or both. This is intentional
+(ICO-007, WCAG 4.1.2): an icon is either purely presentational (aria-hidden) or
+carries meaning (an accessible name), never ambiguous.
+
+```django
+{% bw_icon "search" decorative=True %}          {# beside a visible label #}
+{% bw_icon "trash" label="Delete item" %}       {# standalone, meaningful #}
+```
+
+You rarely call `bw_icon` directly for the icon *inside* a `bw_button` or
+`bw_nav` item: those tags take an `icon="..."` argument and handle the a11y
+pairing for you. Reach for `bw_icon` directly only for a standalone icon in your
+own markup, where this rule applies.
+
+## Development
+
+Python package:
+
+```
+pip install -e ".[dev]"
+pytest
+```
+
+Frontend build (compiles tokens + component assets into the package's static
+dir; see `frontend/README.md`):
+
+```
+npm install
+npm run build
+```
+
+## Licence
+
+MIT. See [LICENSE](LICENSE).

django_brickwork-1.0.0rc1/README.md

@@ -0,0 +1,157 @@
+# brickwork
+
+A brand-agnostic, app-facing professional UI substrate for server-rendered
+Django, on the ecosystem stack: Tailwind 4 (CSS-first), Alpine 3, HTMX 2,
+Django 6.0. It provides the application shell, navigation and active-route
+resolution, an accessible form-field renderer, and interaction primitives
+(modal, toast, dropdown, combobox, tabs, disclosure) wrapped behind stable
+Django components.
+
+**This is not a Django-admin skin.** Its value is the professional baseline:
+WCAG 2.2 AA as a *tested* guarantee (axe-core in CI, not a claim), RTL via
+logical properties, a real themeable dark-mode system, and four composable
+theme axes (brand x theme x density x direction). Applications provide data,
+permissions and business behaviour; the substrate provides structure,
+presentation and interaction conventions.
+
+> Status: **0.16.0, graduating to public PyPI.** The five semver-governed
+> public-API contracts (token, template, navigation, interaction, JavaScript)
+> are live, and every component passes two hard gates: is it accessible
+> (axe-core WCAG 2.2 AA in CI) and is it beautiful by default. The surface is
+> complete: the application shell and nav, the beautiful-by-default token system
+> (elevation, state overlays, type roles, motion, borders, with fine colours
+> derived live from a small load-bearing brand set via `color-mix()`), the
+> interaction set (modal, toast, dropdown, combobox, tabs, disclosure, tooltip,
+> slide-over), forms with the whole-form renderer and the HTMX 422 loop, the
+> data table with sortable and selectable modes, the feedback and input-chrome
+> primitives, the wizard/stepper, and a machine-readable token contract with a
+> per-tenant brand-CSS emitter. The design of record is the spec and brief in
+> the icvoss/oss umbrella:
+> - Spec: `docs/specs/django-brickwork/` (the five versioned public-API contracts).
+> - Design + branding + integration: `docs/DESIGN.md`, `docs/BRANDING.md`,
+>   `docs/INTEGRATION.md`, `docs/ADOPTION.md`.
+> - Changelog: `CHANGELOG.md` (0.1.0 through 0.16.0).
+
+## Documentation
+
+- [docs/DESIGN.md](docs/DESIGN.md): the canonical token reference; every
+  `--bw-*` name, default value, and derivation rule.
+- [docs/BRANDING.md](docs/BRANDING.md): how a consuming app brands brickwork
+  (the load-bearing token minimum, dark mode, the four axes, the fg-on-accent
+  contrast trap, and dynamic per-tenant / per-user theming recipes).
+- [docs/INTEGRATION.md](docs/INTEGRATION.md): the greenfield integration
+  cookbook, the seams a consuming app wires end to end (settings and static, nav
+  config, context processor, a worked HTMX 422 form, the chrome/body boundary).
+- [docs/ADOPTION.md](docs/ADOPTION.md): the strangle guide for migrating an
+  existing app onto brickwork cluster by cluster (multi-host, asset coexistence,
+  the htmx floor).
+- [frontend/README.md](frontend/README.md): the in-repo build that compiles
+  the shipped static assets.
+
+## Install
+
+```
+pip install django-brickwork        # from pypi.icvoss.com (private index)
+```
+
+```python
+INSTALLED_APPS = [
+    "brickwork",
+    # ...
+]
+```
+
+The compiled CSS and JS ship inside the package and are referenced with plain
+`{% static %}`; no build-tool dependency (django-vite / django-tailwind) is
+imposed on consumers. Consumers provide their own Alpine 3 +
+`@alpinejs/focus` (and optionally htmx 2) via their own frontend build; brickwork
+registers behaviour onto the host Alpine instance and never calls
+`Alpine.start()`.
+
+### htmx floor: htmx >= 2.0
+
+brickwork's interaction contracts (the HTMX 422 form-swap loop, toast delivery
+via `hx-swap-oob`, modal dismissal via the `HX-Trigger: bw:modal:close` response
+header, combobox server filtering) are built and CI-gated on **htmx >= 2.0**
+only. htmx 1.9 is out of contract (BR-BW-HTMX-010): htmx 2 changed default
+response handling in ways the 422 loop relies on, and the interaction suites only
+ever exercise htmx 2. A brownfield app on htmx 1.9 should upgrade htmx to 2.x as a
+prerequisite before adopting brickwork's interaction primitives; see
+[docs/ADOPTION.md](docs/ADOPTION.md).
+
+## Contracts
+
+brickwork's public API is five versioned contracts (see the spec): **token**,
+**template**, **navigation**, **interaction (HTMX)**, and **JavaScript
+(Alpine)**. Template block names, HTMX target IDs, Alpine component names,
+event names and token names are semver-governed.
+
+## Usage
+
+### Tags vs includes
+
+Some components are consumed as **template tags**, others via `{% include %}`.
+This is deliberate: a component that carries logic (variant validation, a11y
+enforcement, icon resolution) ships as a tag so that logic is not duplicated at
+every call site; a purely structural component is an include the consumer fills
+with context.
+
+- **Tags** (load the library first): `{% bw_icon %}`, `{% bw_button %}`,
+  `{% bw_badge %}`, `{% bw_alert %}`, `{% bw_nav %}`, `{% bw_field_widget %}`.
+
+  ```django
+  {% load brickwork_components brickwork_icons brickwork_nav %}
+  {% bw_button label="Save" variant="primary" %}
+  {% bw_badge label="New" variant="info" %}
+  ```
+
+  The `_button.html` / `_badge.html` / `_alert.html` template files exist but are
+  the tags' own render targets, **not** a consumer-facing `{% include %}` API.
+  Call the tag, not the partial.
+
+- **Includes** (structure you fill with context): `_page_header.html`,
+  `_data_table.html`, `_pagination.html`, `_empty_state.html`,
+  `_filter_bar.html`, `_spinner.html`, and the form partials `forms/_field.html`
+  / `forms/_form_errors.html`.
+
+  ```django
+  {% include "brickwork/components/_data_table.html" with table_id="gadgets" columns=columns rows=rows %}
+  ```
+
+### Icons: decorative or labelled, always
+
+`{% bw_icon %}` **requires** exactly one of `decorative=True` or `label="..."`,
+and raises `TemplateSyntaxError` if given neither or both. This is intentional
+(ICO-007, WCAG 4.1.2): an icon is either purely presentational (aria-hidden) or
+carries meaning (an accessible name), never ambiguous.
+
+```django
+{% bw_icon "search" decorative=True %}          {# beside a visible label #}
+{% bw_icon "trash" label="Delete item" %}       {# standalone, meaningful #}
+```
+
+You rarely call `bw_icon` directly for the icon *inside* a `bw_button` or
+`bw_nav` item: those tags take an `icon="..."` argument and handle the a11y
+pairing for you. Reach for `bw_icon` directly only for a standalone icon in your
+own markup, where this rule applies.
+
+## Development
+
+Python package:
+
+```
+pip install -e ".[dev]"
+pytest
+```
+
+Frontend build (compiles tokens + component assets into the package's static
+dir; see `frontend/README.md`):
+
+```
+npm install
+npm run build
+```
+
+## Licence
+
+MIT. See [LICENSE](LICENSE).

django_brickwork-1.0.0rc1/pyproject.toml

@@ -0,0 +1,128 @@
+[build-system]
+requires = ["setuptools>=68.0", "wheel"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "django-brickwork"
+version = "1.0.0rc1"
+description = "Brand-agnostic, app-facing professional UI substrate for server-rendered Django (Tailwind 4, Alpine 3, HTMX 2). Accessible by construction; not a Django-admin skin."
+readme = "README.md"
+license = "MIT"
+requires-python = ">=3.12"
+authors = [{name = "Nigel Copley"}]
+classifiers = [
+    "Development Status :: 4 - Beta",
+    "Environment :: Web Environment",
+    "Framework :: Django",
+    "Framework :: Django :: 6.0",
+    "Intended Audience :: Developers",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.12",
+    "Topic :: Software Development :: User Interfaces",
+]
+keywords = [
+    "django",
+    "ui",
+    "design-system",
+    "tailwind",
+    "alpine",
+    "htmx",
+    "accessibility",
+    "wcag",
+    "components",
+]
+# Django 6.0 floor: the package uses core template partials
+# ({% partialdef %} / render(request, "t#partial")) with no compat shim.
+#
+# Django is the ONLY hard runtime dependency. Deliberately NOT depended on
+# (build-tool research 2026-07-30, a library inherits every dep five times):
+#   - django-htmx: brickwork's own need is one boolean (HX-Request header). It
+#     inlines that check and duck-types request.htmx when a consumer already
+#     runs django-htmx. Offered as the optional [htmx] extra, never forced.
+#   - django-vite: unnecessary. brickwork ships STABLE (non-hashed) asset
+#     filenames referenced by plain {% static %}; there is no Vite manifest to
+#     resolve. (Also stale: no Django 5.x/6.x support.)
+#   - django-tailwind / -cli: irrelevant. They manage a Tailwind build inside a
+#     live Django project; brickwork compiles its CSS in its OWN repo (Vite +
+#     @tailwindcss/vite) and ships the precompiled artefact.
+# Tailwind/Alpine/HTMX are FRONTEND runtime (loaded via <link>/<script> against
+# the shipped static assets), not Python packages. @alpinejs/ui + @alpinejs/focus
+# are host-owned peer deps delivered by the consumer's own Vite/npm build.
+dependencies = [
+    "Django>=6.0",
+]
+
+[project.urls]
+Homepage = "https://github.com/icvoss/django-brickwork"
+Documentation = "https://github.com/icvoss/django-brickwork"
+Changelog = "https://github.com/icvoss/django-brickwork/blob/main/CHANGELOG.md"
+"Issue Tracker" = "https://github.com/icvoss/django-brickwork/issues"
+"Source Code" = "https://github.com/icvoss/django-brickwork"
+
+[project.optional-dependencies]
+# Optional: consumers already running django-htmx get brickwork's HTMX-aware
+# helpers using the richer request.htmx surface. brickwork's core never imports
+# it (it inlines the HX-Request header check + duck-types request.htmx), so
+# consumers without this extra are unaffected.
+htmx = ["django-htmx>=1.28"]
+dev = [
+    "pytest>=8.0",
+    "pytest-django>=4.8",
+    "pytest-cov>=5.0",
+    "django-htmx>=1.28",
+    "ruff>=0.5.0",
+    "mypy>=1.10",
+]
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+# Ship templates, the compiled CSS/JS/token artefacts (built by the frontend
+# pipeline into static/brickwork/dist), the vendored icon artwork the registry
+# loads at import, the DTCG token source, and the PEP 561 typed marker.
+brickwork = [
+    "py.typed",
+    "templates/**/*.html",
+    "static/**/*",
+    "icons/vendor/**/*.svg",
+    "tokens/source/**/*.json",
+]
+
+[tool.pytest.ini_options]
+DJANGO_SETTINGS_MODULE = "tests.settings"
+# "." (repo root) so `tests.settings` resolves as a package; "src" for the
+# package. NOT "tests" itself: that would put tests/'s contents at top level and
+# shadow the `tests` package, breaking the `tests.settings` import (CI-caught).
+# The seams leg additionally needs `brickwork_testapp` importable; its CI step
+# and the a11y fixtures set PYTHONPATH=src:.:tests for that.
+pythonpath = ["src", "."]
+testpaths = ["tests"]
+
+[tool.ruff]
+target-version = "py312"
+line-length = 120
+src = ["src"]
+
+[tool.ruff.lint]
+select = ["E", "W", "F", "I", "B", "UP", "N", "SIM"]
+ignore = ["E501", "SIM105"]
+
+[tool.ruff.lint.isort]
+known-first-party = ["brickwork"]
+
+[tool.ruff.format]
+quote-style = "double"
+
+[tool.mypy]
+python_version = "3.12"
+strict = false
+
+[tool.coverage.run]
+source = ["src"]
+omit = ["*/tests/*"]
+
+[tool.coverage.report]
+fail_under = 90
+show_missing = true
+exclude_lines = ["pragma: no cover", "if TYPE_CHECKING:", "if __name__ =="]

django_brickwork-1.0.0rc1/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

django_brickwork-1.0.0rc1/src/brickwork/__init__.py

@@ -0,0 +1,20 @@
+"""brickwork: a brand-agnostic, app-facing professional UI substrate for Django.
+
+Provides the application shell, navigation and active-route resolution, an
+accessible form-field renderer, and interaction primitives (modal, toast,
+dropdown, combobox, tabs, disclosure) wrapped behind stable Django components,
+on the ecosystem stack (Tailwind 4 CSS-first, Alpine 3, HTMX 2, Django 6.0).
+
+This is NOT a Django-admin skin. Its value is the professional baseline:
+WCAG 2.2 AA as a tested guarantee, RTL via logical properties, a real themeable
+dark-mode system, and four composable theme axes (brand x theme x density x
+direction). See docs/specs/django-brickwork/ in the icvoss/oss umbrella for the five
+versioned public-API contracts (token, template, navigation, interaction,
+JavaScript).
+
+The design-token layer lives in the framework-neutral ``brickwork.tokens``
+sub-module; a separate ``brickwork_tokens`` package is deferred until a
+non-Django consumer earns the split.
+"""
+
+__version__ = "1.0.0rc1"

django_brickwork-1.0.0rc1/src/brickwork/apps.py

@@ -0,0 +1,25 @@
+"""Django app configuration for brickwork.
+
+The ``AppConfig.ready()`` hook is where any system checks for the token/template
+contracts are registered. Navigation duplicate-key validation is enforced by the
+consuming project calling ``validate_nav_config()`` at import time
+(BR-BW-NAV-002), not from ``ready()``, since brickwork ships no nav config of its
+own. Kept minimal in the scaffold; populated as the check subsystem lands in
+Phase 0.
+"""
+
+from __future__ import annotations
+
+from django.apps import AppConfig
+
+
+class BrickworkConfig(AppConfig):
+    name = "brickwork"
+    verbose_name = "brickwork UI substrate"
+    default_auto_field = "django.db.models.BigAutoField"
+
+    def ready(self) -> None:
+        # Phase 0: register system checks (token/template/nav contract guards)
+        # here. Intentionally empty until the check subsystem lands; an install
+        # imports cleanly with no models.
+        pass