DQIII8: Instructions file for Claude Code

DQIII8 — Architecture Kernel

Autonomous AI orchestration engine (VPS, SSH-only). UI: Telegram @YourBotName | CLI: dq cc / dq loop / dq status

Routing Tiers (Cost-First — STRICT)

Anthropic-only vigente (directiva usuario 2026-08-18): Sonnet (default) → Opus (plan-review/ revisión adversarial final únicamente). Cadena multi-tier gratuita (C→B→B+→B++) DORMANTE, no eliminada — ver .claude/rules_db/archive/multi-tier-dormant-2026-08.md. Full table + decision algorithm → .claude/rules/03_tiering_and_routing.md

System Map

• DQ Pipeline (7 steps): Classify → Retrieve → Gate → Amplify → Route → Execute → Memory
• DB: database/dqiii8.db (schema_v2.sql — source of truth, now also holds session_memory; sibling: dqiii8_knowledge.db knowledge/vector. dqiii8_history.db and dqiii8_metrics.db.old are frozen post-migration artifacts)
• Writing to agent_actions: use bin/core/action_log.py's shared helpers (resolve_project_safe(), generate_request_id()) — never hand-build the row. Column families and trigger contract: .claude/rules/01_database_mutations.md
• Hooks (15): .claude/hooks/ | Skills (22): .claude/skills/ | Agents (17): .claude/agents/
• Contextual rules (11): .claude/rules_db/ — not read directly; injected per tool call by rules_dispatcher.py — 2 files minimum (_ALWAYS), 13 in the reachable ceiling case, drawn from both .claude/rules_db/ and .claude/rules/ (see .claude/rules/02_hooks_and_permissions.md). Counts on this line are validator-enforced (check_claude_md_counts() in validate_rules_registry.py).
• Entry: bin/core/openrouter_wrapper.py | Director: bin/director.py
• Dispatch (CC↔dqiii8): bin/core/dispatch.py — thin subprocess shim; sync + async via detached worker + atomic JSON envelope

New audit reports and audit docs are never committed — full stop. Both docs/audits/*.md and database/audit_reports/*.md are gitignored with no negation, so anything written today stays untracked. Their durability does NOT come from git — it comes from two independent off-VPS channels: bin/tools/backup_audit_docs.sh (mutual Netcup↔Hostinger rsync, dated snapshots, no --delete mirror) and bin/tools/telegram_audit_backup.py (per-file upload to a single allowlisted Telegram chat). Both read their targets/credentials from env vars only. Deleting an untracked file under either path is effectively irreversible once both backups roll — treat these files with the same care as tracked ones even though git status won't show them. Exception, already in history: commit af869db (2026-08-18) deliberately force-added 35 pre-2026-08-18 files under database/audit_reports/ as a one-time archival decision — git ls-tree -r HEAD --name-only database/audit_reports | wc -l confirms 35 tracked today. That corpus is grandfathered, not a precedent: don't git add -f a new audit doc into either directory without the same explicit human call that created this exception.