Django Code One Task Group

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Implement one bucket of Django tasks from a plan’s task group end to end, in any Django project, with one quality baseline up front and one consolidated validation pass at the end, and with the container-backed integration stage serialized behind a repository-wide lock.

Purpose

iru-django-code-one-task-group is the Django counterpart to iru-php-code-one-task-group and iru-nestjs-code-one-task-group, built on the four Python gate skills. Step 1 detects once the runner prefix, manage.py location and Django version, test and production settings modules, app layout, API style (DRF with or without drf-spectacular, Ninja, plain views), test runner, and — decided by what a test needs, not by its name — the fast and integration selections. It captures one pre-change iru-python-code-quality baseline, then implements each task through iru-django-code-one-task, in parallel agents when the group is parallelizable. Tasks that change models in the same app, share a urls.py, settings module, admin.py or models.py, or depend on another task’s new code always run sequentially so migrations and edits cannot collide.

Step 3 validates the bucket once, cheapest first, every check delegated to an iru-gate-runner agent: license headers, docstrings, the Django framework checks (manage.py check, makemigrations --check --dry-run with migration-conflict detection, spectacular --validate when drf-spectacular is installed, and check --deploy as information), scoped fast tests, an 80% line-coverage gate measured from container-free tests alone, the full fast suite, Ruff/mypy (plus Bandit, djLint, django-upgrade when configured) diffed against the baseline, and last the integration tier behind the atomic mkdir-based .integration-test.lock (stale after 60 minutes, bounded ~45-minute wait, released on every exit path). An integration stage that cannot run is reported unverified, never silently skipped, and never affects the coverage verdict.

For a bucket that touched templates, static assets, template tags or HTML-rendering views, Step 3.10 adds a browser UI stage under the same lock (iru-python-test ui: pytest-playwright with live_server). It checks that every changed screen and component has a capture in .ui-screenshots/ for each state × .ui-quality.yml direction × theme, and applies the axe accessibility level — enforce violations fail the bucket and are fixed in the owning task, report ones are listed, off is noted. A missing Playwright browser or missing UI test wiring (pytest-playwright, axe-playwright-python, a ui marker, tests/ui/ui_screenshots.py, .ui-quality.yml, detected in Step 1) is reported unverified, never passed. The UI contract is described in Building user interfaces.

Purpose group

Python Development Tooling

Plugin

Shipped by the iru-python plugin of the ai-catalog marketplace (install with /plugin install iru-python@ai-catalog; see Plugins).

Invocation

/iru-django-code-one-task-group <bucket text>

Inputs

Argument Required Description Default

Bucket text

Yes

Every Django-tagged task/sub-task in the bucket with its own text, the group’s Parallelizable verdict, and any relevant "Current code state" context.

None — always invoked with a specific bucket’s text, by iru-code-one-task-group.

Outputs

  • Source, test and migration files created or modified per task, via iru-django-code-one-task.

  • License headers and docstrings kept current across every file the bucket touched, checked once for the whole bucket.

  • Clean Django framework checks: check, makemigrations --check and, when applicable, the drf-spectacular schema validation.

  • Fast tests reaching at least 80% line coverage for the changed/new production files, measured without the integration tier.

  • No new Ruff, mypy/pyright or other configured-tool issues versus the one baseline; security-relevant findings (Ruff S, DJ001/DJ006/DJ007) fixed or explicitly accepted.

  • For UI work: the browser UI stage outcome — screenshot counts per kind under .ui-screenshots/, matrix gaps or malformed names fixed, the accessibility level applied (or "accessibility: opted out" for none) and its violations by rule id, or unverified with the reason.

  • implementation_plan.md with each task’s checkbox checked and its note replaced by the final outcome (fast-test coverage, quality, integration and UI results).

  • A bucket report to the caller: detected shape and the fast/integration selectors, per-task results, framework check results including informational deploy warnings, security findings, accepted coverage exceptions, the integration outcome (passed, fixed, unverified with reason, or no integration tests) and lock behavior, the UI stage outcome and the per-task Screen › Region › Component trees, and any blocked task. When .ui-quality.yml is missing in a repository that already has UI code, it doesn’t assume enforce: before the first UI task it asks once, pre-selected from iru-explore’s `Accessibility: line, and writes the file.

Execution flow

flowchart TD A[Start /iru-django-code-one-task-group] --> S0["Step 0: only one integration run\nrepository-wide, enforced by the lock"] S0 --> B["Step 1: detect project shape, fast vs integration\nselections, Docker availability"] B --> B2["Capture one pre-change quality baseline\n(iru-python-code-quality, via iru-gate-runner)"] B2 --> C{"Bucket Parallelizable and\nno same-app model or file overlap?"} C -- yes --> D["Step 2: invoke django-code-one-task\nfor every task concurrently"] C -- no --> E["Step 2: invoke django-code-one-task\none at a time in plan order"] D --> F["Confirm or backfill each task's box;\nnotify user; blocked tasks excluded"] E --> F F --> G["Step 3: derive scope from agent reports\nand git status/diff"] G --> G1["3.1 license headers, 3.2 docstrings"] G1 --> G2["3.3 Django framework checks\ncheck, makemigrations, spectacular"] G2 --> G3["3.4 scoped fast tests"] G3 --> G4{"3.5 fast-test coverage\n80% per target?"} G4 -- no --> G5["Add fast tests via the owning task"] G5 --> G3 G4 -- yes --> G6["3.6 full fast suite, 3.7 migrations replayed"] G6 --> G7{"3.8 new quality issues\nvs baseline?"} G7 -- yes --> G8["Fix, re-run 3.4 and 3.6"] G8 --> G7 G7 -- no --> H{"Integration tests exist,\nare affected, and environment available?"} H -- no --> H1["Report integration stage\nnot applicable or unverified"] H -- yes --> I["3.9a: acquire mkdir lock\n(wait, break stale, or time out)"] I -- timed out --> H1 I -- acquired --> J["3.9: run integration tests once"] J --> J2{"UI touched?"} J2 -- yes --> J3["3.10: browser UI tests under the lock\n(playwright, screenshot matrix, axe level);\nunverified if no browser or wiring"] J2 -- no --> K["3.9b: release lock"] J3 --> K K --> L["Step 4: replace each task note\nwith final outcome; notify user"] H1 --> L L --> M["Step 5: report the bucket's outcome\nto the caller"]

Dependencies

Invokes

  • Django Code One Task — Step 2, once per task in the bucket (concurrently or sequentially), via the iru-isolated-skill-executor agent; implements the task, writes its tests, generates its migration, runs only the fast tests it touched and checks off its own checkbox.

Each of the following is invoked via the iru-gate-runner agent so reports stay out of this skill’s context:

  • Python Code Quality — Step 1 (baseline) and Step 3.8 (regression check against it).

  • Check License — Step 3.1, license headers for every file the bucket touched.

  • Python Docstrings — Step 3.2, docstrings for the production files.

  • Python Test — Steps 3.4, 3.6, 3.9 and 3.10, scoped fast tests, the full fast suite, the integration run and, for UI work, the ui run (under the lock the skill already holds).

  • Python Coverage — Step 3.5, fast-test line coverage for the bucket’s targets.

Invoked by

Related agents

  • iru-isolated-skill-executor — one per task in Step 2, so each task’s transcript stays out of this skill’s context.

  • iru-gate-runner — the baseline (Step 1) and every validation check (Step 3), including the Django framework checks and the lock-protected integration run.

Source

SKILL.md on GitHub — the file this page was generated from.