DACore · coming December 2026

How AIRULES-DACORE keeps AI agents writing secure code

DACore is built so a human or an agent can add a plugin without touching the admin core. That only works if the agent reads the same laws every time. AIRULES-DACORE is the overlay on the framework AIRULES pack: docs 00–22 stay, docs 30–37 add DACore, and Cursor loads 08-dacore.mdc on every chat. Copy that folder into a DACore project as AIRULES/. Do not keep both variants side by side. The agent would have two sources of truth and would eventually patch DACore “just this once”.

Common mistakes

Two packs, one folder name

Official docs for the framework pack stay at For AI agents (llms.txt, MCP, GitHub AIRULES). This article is the DACore overlay: why an agent that already writes correct DotApp still needs extra laws once a desk exists.

Wire Cursor (and any markdown-reading agent)

After DotApp and DACore are on disk:

Copy-Item -Recurse -Force "AIRULES-DACORE" "path\to\project-root\AIRULES"
New-Item -ItemType Directory -Force -Path "path\to\project-root\.cursor\rules" | Out-Null
Copy-Item -Force "path\to\project-root\AIRULES\cursor\rules\*.mdc" "path\to\project-root\.cursor\rules\"
Copy-Item -Force "path\to\project-root\AIRULES\cursor\AGENTS.md" "path\to\project-root\AGENTS.md"

Tell the agent: read AIRULES/00-AGENT-CONTRACT.md first. Follow AIRULES for all DotApp work. Always-on Cursor rules include the core laws plus 08-dacore.mdc (menu, rights, pages, AI tools, the DACore file ban). Full copy-paste lives in AIRULES-DACORE/INSTALL.md inside the module pack. This site summarizes; it does not republish every rule file.

Hard laws that make the code safe

These are the rules that stop an agent from shipping an insecure or un-updatable app. They are not style nits.

1. Edit boundaries. Freely: app/config.php and app/modules/<YourModule>/ (including that module’s assets). Never: app/parts/, kernel, vendor, dotapper.php, index.php. DACore folder: same rank as core by default.
2. No raw writes to dacore_menu, dacore_ai_tools, dacore_installations, dacore_modules, plugin logs, settings, notifications tables, or users_rights*. Use DotApp::call("DACore:…").
3. Own Rights middleware. #DACore:AuthTest@check! does not apply the rights you pass. Copy the TestInstalatora pattern.
4. dainstall.php + init/ for modules under DACore. Never install.php in the plugin ZIP. Never apply that pattern to DACore itself.
5. Page@withMenu! — no second admin chrome. Ask shared vs module-own menu before a new DACore module.
6. Secure channel. Multi-field submit is <fo-rm> with formName between the tags. Row actions use $dotapp().load() and encrypted ids. PHP re-checks. Cover the UI until the request ends. Deletes use a graphical confirm.
7. Tables {lowercase_modulename}_*. Never dacore_* for your data. Session state in DSM::use('Shop'), never $_SESSION.
8. Lists that can grow ship pagination and an AJAX pager in v1. Lookup lists ship AJAX search unless the user declined.
9. Uploads via $dotapp().uploadFile. PHP rejects executables (extension + MIME + headers).
10. AI tools. Empty rights means invisible. Search DACore read-only before inventing a widget that already exists.

Together they mean: the agent writes a plugin DACore can install, the next DACore ZIP can overwrite the core without destroying your work, and a missing right still fails on the server. That is why DACore is suitable for AI-assisted coding. The model is not trusted. The contract is.

What 30–37 add

Copy-paste patterns sit in examples/EX-D01 through EX-D05: skeleton, admin page, AI tool, installer, notifications. The agent should open one example file per task instead of swallowing the whole tree.

Why this beats “just prompt the model”

An unconstrained agent given “add users to my DotApp admin” will reach for Laravel, patch app/modules/DACore, skip CRC, and skip uninstall. AIRULES-DACORE makes the correct path the default: new work in YourModule, APIs for menu and rights, installer symmetry, PHP as the last gate. Humans benefit too — the same checklist is in 17-CHECKLISTS.md — but the overlay exists because coding agents do not inherit tribal knowledge from your last project.

DACore still embeds an assistant for operators inside the desk. That assistant is a different layer (tool registry, intent router, confirmation on writes). AIRULES-DACORE is for the programmer agent in Cursor (or Claude, or GPT) that authors the plugin. Do not confuse the two. Both are designed. Both refuse to improvise security.