{
  "markdown": "# DAW — Dilux Agentic Workflow\n\n[![verify](https://github.com/soydiloreto/dilux-agentic-workflow/actions/workflows/verify.yml/badge.svg)](https://github.com/soydiloreto/dilux-agentic-workflow/actions/workflows/verify.yml)\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](LICENSE)\n\n**A development pipeline your coding agent has to walk through.** Phases in order, gates it cannot\ntalk its way past, auditors that did not write the code they review, and state that survives closing\nthe terminal.\n\nWorks with **Claude Code**, **Codex CLI**, **Copilot CLI**, **Cursor**, **Gemini CLI** and\n**OpenCode** — one method, six wirings.\n\n![The DAW pipeline: six phases and the gates between them](docs/assets/daw-pipeline.png)\n\n## Install\n\n**As a plugin, and nothing of DAW's lands in your repository.** The method lives in the tool; what\nstays with the project is the `AGENTS.md` you write, the documents each phase produces, and the\npipeline's state.\n\n| Tool | How |\n|---|---|\n| **Claude Code** | `/plugin marketplace add soydiloreto/dilux-agentic-workflow`, then `/plugin install daw@dilux --scope project` |\n| **Copilot CLI** | [`.github/INSTALL.md`](.github/INSTALL.md) — written as steps to hand to your agent |\n| **OpenCode** | [`.opencode/INSTALL.md`](.opencode/INSTALL.md) — same, and it registers the plugin in `opencode.json` |\n\nThose two need their own steps for a reason worth knowing before you start: **Copilot reads the\nplugin manifest for its skills and ignores the hooks in it**, so the gates ride user-level hooks\ninstead — install the skills and stop, and it looks alive while enforcing nothing.\n\n> **Codex CLI, Cursor and Gemini CLI are next.** All three already run the method, and the test\n> suite drives each one's real hook with that tool's own event format — what is not finished is the\n> plugin path end to end. Today they install by copying the method into the repository, which works\n> and is one command: see [`docs/INSTALL.md`](docs/INSTALL.md).\n\nCopying the method in is also what you want on **any** of the six once you need to **change** how\nthe method works, rather than only use it. Both ways, and what each one costs, are in\n[`docs/INSTALL.md`](docs/INSTALL.md).\n\nThen open your agent in the project and ask it for something. The pipeline starts on its own.\n\n> 🌍 **On language.** This repo is in English; DAW is not. Its files are **prompts**, and they carry\n> an explicit directive: answer in the language the user writes in, and write every artifact — PRDs,\n> specs, commit messages — in that same language. Ask in Spanish, get a Spanish PRD.\n\n## The problem it solves\n\nPut a coding agent on a real repository and the same three things happen:\n\n- **It skips ahead** — straight to the implementation, before anyone agreed on what was being built.\n- **It forgets** — forty messages in, the decision you made an hour ago is gone.\n- **It drowns** — give it forty rules and it follows the ones nearest the end of the context window.\n\nNone of these is fixed by a better prompt. They are structural.\n\n## What it does\n\n`CLASSIFY → DEFINE → PLAN → CODE → VERIFY → RELEASE`, one phase at a time, with a gate between each\npair and your approval on every arrow. Only the current phase's rules enter the context. Every phase\ncommits what it produced. The state lives on disk, so closing the terminal costs you nothing.\n\nAnd the ceremony matches the size of the request: a question gets an answer, a ten-line fix gets a\nshort lane, a feature gets the full run.\n\n→ [**How it works, in detail**](docs/METHOD.md) — the phases, the tiers, the PRD, security.\n\n### The distinction the whole thing rests on\n\nA rule written in a prompt is a **promise**. The model can forget it, misread it, or decide this once\ndoes not count.\n\nA rule enforced by a hook is a **guarantee**. Before every write, code outside the model reads the\nstate and refuses a transition the graph does not carry, and a write of product source from a phase\nwhose rules forbid it. There is no talking past either one, because the decision never reaches the\nmodel. Try to write code with no approved spec and the write does not happen — not \"the agent\napologizes and continues\".\n\n**Where that guarantee ends, stated plainly:** it covers the write tools. A shell command does not go\nthrough them, so `bash -c 'cat > src/x.py'` reaches the disk. DAW does not try to parse your shell to\ncatch it — every spelling it failed to anticipate would fail open, and a guard that reads as total\nand is not is worse than an honest gap. What it does instead is **notice**, and say so.\n\nThat is the line through every decision here: if a rule matters, it is executable. If it cannot be\nexecuted, it does not get to call itself a gate.\n\n### Not every gate is the same strength, and DAW says which\n\nA gate is refused-without and recorded. What **backs** the claim is graded, and the grading is\nwritten down instead of implied: the PRD's gate rests on a receipt naming the document's current\nbytes, the commit gate asks git, and the rest rest on the model's record of what it did.\n\nThat grading is not ours. Supply chain security calls the artifact an **attestation** and the graded\nversion **provenance** — at [SLSA](https://slsa.dev/spec/v1.0/requirements) level 1 it may be\nself-declared by whoever did the work, and from level 2 it is produced by the platform and cannot be\nforged by the party doing the work. A required status check is the same idea in the shape everyone\nuses daily: you cannot merge until CI reports the check, and you cannot report it for CI.\n\n**Two gates stay self-declared on purpose.** `sast` has nothing to run — it is a model reading code,\nand a receipt would dress a report up as proof. `tests` would mean DAW running your suite in your\nrepository, guessing your runner and your environment: CI can do that because CI *is* the\nenvironment, and a gate that cannot be satisfied honestly gets satisfied dishonestly. Both stay in\nthe pipeline, gated and sequenced, and stay honest about what they are.\n\n→ [**Which gate rests on what, and why**](docs/RATIONALE.md#16-a-gate-is-an-attestation-and-they-are-not-all-the-same-strength)\n\n## Status\n\n- **Claude Code** — exercised end to end, and **all four acceptance checks pass against the live\n  tool** (2.1.220, 2026-07-28; the record is in `scripts/acceptance.md`). Told to write source with\n  no approved spec, the write is refused by the hook rather than declined by the model.\n- **OpenCode** — the same four, against the live tool (1.18.9, 2026-07-29). That session is also\n  where two defects were found, which is the argument for doing this by hand.\n- **Copilot CLI** — three of the four (1.0.75, 2026-07-29). The fourth is **detected and not\n  prevented**, and the ceiling is the tool's: its post hook cannot refuse anything.\n- **Codex CLI, Cursor, Gemini CLI** — each adapter is driven through its own hook, with its own\n  event format, by the test suite: it must refuse an illegal transition and let a legal one through.\n  What has not been done for these three is a full session against the live tool, so treat their\n  status as *verified at the boundary, unverified in the wild*. Reports welcome.\n\n```bash\nbash scripts/verify_install.sh    # the full suite: install, FSM, and every adapter's enforcement\npython3 scripts/lint_method.py    # the prose against the graph, the catalog and the filesystem\npython3 scripts/mutate.py         # breaks DAW on purpose and checks the suite notices\n```\n\n## Docs\n\n| | |\n|---|---|\n| [`docs/INSTALL.md`](docs/INSTALL.md) | Both ways in, upgrading, uninstalling, what lands where |\n| [`docs/METHOD.md`](docs/METHOD.md) | How a request flows, and why each part is shaped that way |\n| [`docs/AGENTS-MD.md`](docs/AGENTS-MD.md) | The one file you write — and why a missing heading fails quietly |\n| [`docs/RATIONALE.md`](docs/RATIONALE.md) | Every decision that could have gone the other way, and its cost |\n| [`docs/DEVELOPMENT.md`](docs/DEVELOPMENT.md) | Internals: the orchestrator, the state machine, the hooks |\n| [`docs/AI-POLICY.md`](docs/AI-POLICY.md) | How AI-generated work is handled here, and who is accountable |\n| [`daw/rules/README.md`](daw/rules/README.md) | The method itself, phase by phase |\n| [`adapters/adapter.schema.md`](adapters/adapter.schema.md) | How to add a seventh tool |\n\n[`CONTRIBUTING.md`](CONTRIBUTING.md) · [`SECURITY.md`](SECURITY.md) ·\n[`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md)\n\n**Something to report?** A bug, an adapter you drove against a real tool, a decision you would have\nmade differently — [each has its own form](https://github.com/soydiloreto/dilux-agentic-workflow/issues/new/choose).\n**A vulnerability goes to a [private advisory](https://github.com/soydiloreto/dilux-agentic-workflow/security/advisories/new), never a public issue.**\n\n## Where it comes from\n\nYears of building production software with teams, where you find out quickly which parts of a process\nearn their cost and which ones everybody routes around. DAW is that way of working, built completely\nfor once, with nothing left as an intention. Every decision in it is one I would defend on its own\nterms, and [`docs/RATIONALE.md`](docs/RATIONALE.md) is where I do.\n\n— Pablo Ariel Di Loreto\n\n## License\n\nApache 2.0. Use it, fork it, adapt it to how your team actually works — that last one is the point.\nThe license grants patent rights explicitly and reserves the names: fork the method freely, call your\nfork something else.\n\nCopyright 2026 Pablo Ariel Di Loreto.\n\n---\n\nBuilt by **[Pablo Di Loreto](https://github.com/soydiloreto)** — Director of Engineering, Microsoft\nMVP for Azure & AI, and someone who got tired of explaining the same process to an agent every\nmorning.\n\nDAW is the framework behind the *Agentic Orchestration* module of **AI-First Builders Lab**, where\nstudents take it apart, rewire it for their own stack, and port it to a second tool.\n",
  "bytes": 9880,
  "sha": "69886b181aa26f96eb99a3df4ce0ec1fc49ccfb9db7e011976e5e3c8f09a5a4b",
  "repo_slug": "luckypadua/gestion-de-vacaciones-daw",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_luckypadua_gestion_de_vacaciones_daw_409f7731/readme"
}