AGENTS.md × Skills: วงจรทำงาน Diagram

AGENTS.md

Rules · Every Session

Governs agent behavior, precedence hierarchy, and testing commands.

Role: Secure TDD Architect
Strict no-comment in source code — documentation lives in mirror files
Authoritative Source of Truth order; beats default agent assumptions
Enforces TASKS / PENDING / console.md cycle and test runs

md/README.md

Model · Think First

The core platform mental model: JSON storage + state-driven workflows.

Mental model: JSON object storage + workflow (txn → state/status)
3 Architectural Planes: access, config, app
8 Design Doctrines: every feature must fit this model; contradictions are design bugs
Determines whether a task requires a config INSERT or code modification

dbdict → Entity → Controller → Facade

Structure · Level 0–3

Strict downward precedence ensures structural integrity across the stack.

When structures conflict, the lower layer always wins
dbdict/<schema>/<table>.sql + GRANT UPDATE is Level 0 ground truth
Facade encapsulates transactions; Controller parses forms and delegates
Jdbc extends ORM without redundant processor/proxy layers

Skills Suite

Execution · Step-by-Step

Autonomous specialized skills invoked at designated pipeline steps.

secure-tdd: Orchestrator inspecting trust boundaries and authN/Z
write-test: Authorizes Red Spec; sbt testOnly must fail initially
owasp-coding + iso-27001: Enforces Green implementation security
mvc-skill (layers), scala-doc (mirror), antigravity (translation)

Doc Mirror & API Contracts

Docs · Colocated

Documentation synchronized in the exact same change set with code.

Doc mirror: app/x/Foo.scala ↔ md/app/x/Foo.md read before editing
DocMirrorSpec fails if comments exist in code or headings remain unsynced
../nocode-api/SKILL.md: API contract for external agents in separate repo
Endpoint alterations must update both contract and implementation atomically

TASKS / PENDING & console.md

Queue · Audit Trail

FIFO task management and comprehensive iteration audit logs.

TASKS.md: Top-down execution, mark ✅, append bullet to ## LOG
PENDING.md: Read-only backlog; do not edit; any conflict raises an issue
console.md: Full explanation per round (action, reason, metrics, errors)
Newest entry is placed on top; terminal outputs brief summary pointing to console

7-Step Sequential Execution Flow

Execution Pipeline

STEP 01 Ingest Context

Auto-load AGENTS.md + MEMORY.md. Translate non-English prompt via antigravity.

STEP 02 Select Task

Read TASKS.md ## TODO. Pick top task. Verify zero conflict with PENDING.md.

STEP 03 Model Doctrine

Evaluate 8 Design Doctrines in README. Decide config INSERT vs code changes.

STEP 04 TDD Decision

Touches code/system = Spec required. Artifact only (doc/JSON) = no spec.

STEP 05 Red / Green / Refactor

Run secure-tdd. Write failing spec (Red), implement code (Green), and prune redundant specs.

STEP 06 Doc Synchronization

Update doc mirror md/app/ and SKILL.md in the exact same commit as code.

STEP 07 Audit & Close

Mark ✅ in TASKS, log in console.md, summarize to terminal, and take next task.

AGENTS.md

กฎ · โหลดทุก session

บทบาท กฎเหล็ก ลำดับความจริง และคำสั่งทดสอบของ Agent ทั้งหมด

บทบาท Secure TDD Architect
กฎ no-comment ใน source code — เอกสารต้องอยู่ที่ doc mirror เท่านั้น
ลำดับ Source of Truth ชัดเจน ชนะ default ของ agent ทุกตัว
ควบคุมขั้นตอน TASKS / PENDING / console และคำสั่ง build/test ทั้งหมด

md/README.md

โมเดล · คิดก่อนทำ

Mental model ของแพลตฟอร์ม: JSON object storage + workflow

Mental model: JSON object storage + workflow (txn → state/status)
3 Architectural Plane: access, config, app
Design Doctrine 8 ข้อ: ทุก feature ต้องวางในโมเดลนี้ก่อน ถ้าขัดคือ design bug
ตัดสินว่า task เป็นเพียง config INSERT หรือต้องเขียนโค้ดเพิ่ม

dbdict → Entity → Controller → Facade

โครงสร้าง · Level 0–3

ลำดับชั้นโครงสร้างระบบ: หากมีข้อขัดแย้ง ชั้นล่างชนะเสมอ

ถ้าโครงสร้างขัดกัน ชั้นล่างชนะ: ฐานข้อมูลคือความจริงสูงสุด
dbdict/<schema>/<table>.sql รวม GRANT UPDATE คือ Level 0
Facade รวม Transaction; Controller รับ Form และกระจายงาน
Jdbc สืบทอด ORM โดยตรง ไม่สร้าง Processor หรือ Proxy ที่ซ้ำซ้อน

Skills

วิธีทำ · เรียกตามขั้น

ชุดเครื่องมือและทักษะเฉพาะทางที่ถูกเรียกตามลำดับไปป์ไลน์

secure-tdd: orchestrator คุมทั้งรอบ วิเคราะห์ trust boundary และ authN/Z
write-test (RED): เขียน Spec แล้ว sbt testOnly ต้อง fail จริง
owasp-coding + iso-27001 (GREEN): เขียนโค้ดตามมาตรฐานความปลอดภัย
mvc-skill (layer), scala-doc (mirror), antigravity (แปลภาษา)

Doc mirror & สัญญาภายนอก

เอกสาร · คู่กับโค้ด

เอกสารและข้อตกลง API ที่ต้องอัปเดตพร้อมโค้ดใน commit เดียวกัน

Doc mirror: app/x/Foo.scala ↔ md/app/x/Foo.md อ่านก่อนแก้ แก้พร้อมโค้ด
DocMirrorSpec fail ทันทีถ้ามี comment ใน source หรือ heading ใน doc ค้าง
../nocode-api/SKILL.md: สัญญาของ /skill/* API สำหรับ agent ภายนอก
เมื่อเปลี่ยน endpoint ต้องอัปเดตใน change เดียวกันเสมอ

TASKS / PENDING & console.md

คิวงาน · รายงานผล

ระบบคิวงาน FIFO และบันทึกรายงานการทำงานฉบับสมบูรณ์

TASKS.md: ทำบนลงล่าง mark ✅ ทีละข้อ, เพิ่ม bullet ใน ## LOG
PENDING.md: backlog ห้ามแตะ ใช้เป็น context เท่านั้น ขัดกัน = raise
console.md: คำอธิบายเต็ม (ทำอะไร, ทำไม, รันอะไร, ผลตัวเลข, อะไร fail หรือข้าม)
Entry ใหม่อยู่บนสุดเสมอ สรุปสั้นใน terminal ชี้ไปที่ console.md

สรุป 7 ขั้นตอนการทำงานทีละสเต็ป

ลำดับการทำงาน

สเต็ป 01 เข้า (Ingest)

AGENTS.md + MEMORY.md โหลดเข้า context อัตโนมัติ prompt ไม่ใช่อังกฤษ แปลผ่าน antigravity ก่อน

สเต็ป 02 เลือกงาน

อ่าน TASKS.md หัวข้อ ## TODO หยิบ task บนสุด เช็ก PENDING.md ว่าไม่ขัดแย้ง

สเต็ป 03 วางในโมเดล

เทียบ README Design Doctrine 8 ข้อ ตัดสินว่าเป็น config INSERT หรือต้องเขียนโค้ด

สเต็ป 04 ตัดสิน TDD

แตะระบบ/โค้ด = ต้องมี spec, งาน artifact ล้วน (เช่น doc/JSON) = ไม่มี spec

สเต็ป 05 Red / Green / Refactor

skill ชุด secure-tdd ทำงาน ต้องรัน sbt จริงทั้งตอน fail (Red) และ pass (Green)

สเต็ป 06 เอกสารคู่โค้ด

อัปเดต doc mirror md/app/ และ SKILL.md (ถ้าเป็น /skill/*) ใน change เดียวกับโค้ด

สเต็ป 07 ปิดงาน & บันทึก

mark ✅, เพิ่ม LOG, บันทึก console.md สรุปสั้นใน terminal แล้วค่อยหยิบ task ต่อไป

AGENTS.md

规则 · 每次会话必载

定义智能体角色、强制性无注释规则及真理源级层。

角色：Secure TDD Architect
源码严格执行 no-comment — 所有文档必须归档在镜像文件中
明确真理源（Source of Truth）优先级，压制智能体默认推断
全面统筹 TASKS / PENDING / console.md 循环及构建测试命令

md/README.md

模型 · 动手前深思

平台核心心智模型：JSON 对象存储与工作流引擎。

心智模型：JSON 对象存储 + 状态驱动工作流（txn → state/status）
三大平面：access（访问）、config（配置）、app（应用）
8 项设计信条：所有功能必须严格嵌入此模型；冲突即视为设计缺陷
判定任务属于配置 INSERT 还是必须编写实体代码

dbdict → Entity → Controller → Facade

结构 · Level 0–3

严格的由下而上权威级层：结构冲突时下层绝对优先。

若结构发生分歧，底层结构永远获胜：底层为基石真理
dbdict/<schema>/<table>.sql 连同 GRANT UPDATE 为 Level 0 最高真理
Facade 统筹事务与模型映射；Controller 解析表单并分派执行
Jdbc 直接继承 ORM，去除无谓的 Proxy 或 Processor 冗余层

Skills 工具集

执行 · 按阶调用

在工作流各关键环节调用的专门化自动化技能组。

secure-tdd：全局编排者，负责信任边界与权限鉴权分析
write-test（RED）：编写测试规约，sbt testOnly 首次执行必须真实失败
owasp-coding + iso-27001（GREEN）：保障实现代码符合最高安全标准
mvc-skill（分层控制）、scala-doc（镜像维护）、antigravity（多语翻译）

Doc Mirror 与 API 契约

文档 · 镜像同步

文档与代码在同一个 Commit 中原子化同步更新。

文档镜像：app/x/Foo.scala ↔ md/app/x/Foo.md 改动前必读，同改同退
若代码存留行内注释或文档标题不一致，DocMirrorSpec 立即报错
../nocode-api/SKILL.md：供外部智能体调用的 /skill/* 外部 API 契约
一旦修改端点，必须在同一次提交中同步更新契约文件

TASKS / PENDING 与 console.md

任务队列 · 审计日志

任务先进先出管理队列与详尽的执行审计追踪。

TASKS.md：自顶向下执行，逐项打勾 ✅，并在 ## LOG 追加条目
PENDING.md：积压待办池，禁止随意改动，仅作只读上下文参考
console.md：单轮次执行详报（所作工作、原因、执行命令、量化数值、报错）
最新记录置于最顶端，并在终端输出精炼总结指引查阅

7 步工作流执行阶段详解

标准作业程序

步骤 01 上下文加载

自动加载 AGENTS.md + MEMORY.md。非英语指令通过 antigravity 翻译。

步骤 02 选取任务

读取 TASKS.md ## TODO 顶层任务，核查 PENDING.md 确保无冲突。

步骤 03 心智对齐

比对 README 8 项设计信条，判定系配置 INSERT 抑或需要编码。

步骤 04 TDD 判定

触及系统/业务代码 = 必须写测试 Spec；纯文档/JSON = 免测试。

步骤 05 红绿重构

运行 secure-tdd。Spec 必须真实失败（红），编码实现（绿），并精简重构。

步骤 06 镜像同步

在同一个代码变更中同步更新 md/app/ 文档镜像及 SKILL.md 契约。

步骤 07 结案归档

打勾 ✅，写入 LOG 与 console.md，向终端输出简报，拾取下一任务。

AGENTS.md

ルール · 全セッション必読

AI の役割、コード内コメント禁止、真実の源泉順序を規定。

役割: Secure TDD Architect
厳格な no-comment 原則 — ソースコード内コメント禁止、文書はミラーに集約
エージェントのデフォルト挙動を上書きする真実の源泉（Source of Truth）
TASKS / PENDING / console.md サイクルとビルド・テストの全管理

md/README.md

モデル · 実装前の思考

JSON オブジェクトストレージとワークフローによるメンタルモデル。

メンタルモデル: JSON object storage + workflow (txn → state/status)
3つのプレーン: access, config, app
8つの設計原則: 全機能はこのモデルに適合必須、矛盾は設計バグと判定
単なる設定 INSERT で済むか、コード実装が必要かを決定

dbdict → Entity → Controller → Facade

構造 · Level 0–3

階層の優先順位: 構造が衝突した際は下位層が常に優先。

不整合時は下位レイヤーが勝利: DB定義が最上位の真実
dbdict/<schema>/<table>.sql + GRANT UPDATE は Level 0 の最高基準
Facade がトランザクションを一元管理、Controller はフォーム解析と委譲のみ
Jdbc は ORM を直接継承し、余計な Proxy や Processor レイヤーを廃止

Skills スイート

実行 · 段階的呼び出し

パイプラインの各段階で自律的に呼び出される専門化スキル。

secure-tdd: トラストバウンダリと権限検証を監督するオーケストレーター
write-test (RED): Spec を記述し、初回 sbt testOnly で確実に失敗させる
owasp-coding + iso-27001 (GREEN): セキュリティ基準を遵守した実装
mvc-skill（レイヤー厳格化）、scala-doc（ミラー更新）、antigravity（翻訳）

Doc Mirror & 外部規約

文書 · コード同期

コードと完全に同一コミットで同期されるドキュメント。

Doc mirror: app/x/Foo.scala ↔ md/app/x/Foo.md 修正前に読み、同時に更新
コード内にコメントが残るか見出しに不整合があれば DocMirrorSpec が即時失敗
../nocode-api/SKILL.md: 外部エージェント用 /skill/* API 契約
エンドポイント変更時は同一チェンジセット内で規約ファイルを更新

TASKS / PENDING & console.md

タスクキュー · 監査証跡

FIFO タスクキューと各イテレーションの完全な実行ログ。

TASKS.md: 上から順に実行、✅ で完了マーク、## LOG に箇条書き追加
PENDING.md: 保留バックログ、編集厳禁、参照専用コンテキスト
console.md: 各サイクルの完全記録（内容、理由、コマンド、数値指標、エラー）
最新エントリを常に最上段に配置し、ターミナルには要約を出力

7段階の実行パイプラインまとめ

ワークフローステップ

STEP 01 コンテキスト読込

AGENTS.md + MEMORY.md を読込。英語以外の指示は antigravity で翻訳。

STEP 02 タスク選定

TASKS.md ## TODO 最上位を抽出。PENDING.md との矛盾がないことを確認。

STEP 03 モデル適合

README の8大設計原則に照合。設定 INSERT かコード記述かを判定。

STEP 04 TDD判定

システム変更 = Spec 必須。純成果物（doc/JSON） = Spec 不要。

STEP 05 Red / Green / リファクタ

secure-tdd を実行。失敗テスト作成（Red）、実装（Green）、重複Spec削除。

STEP 06 ドキュメント同期

md/app/ ドキュメントミラーおよび SKILL.md を同一コミットで更新。

STEP 07 完了 & 記録

✅ マーク、LOG 追記、console.md 記載、ターミナル報告後、次のタスクへ。

AGENTS.md

Regeln · Jede Session

Steuert das Agentenverhalten, die No-Comment-Regel und Testbefehle.

Rolle: Secure TDD Architect
Strikte no-comment Regel im Quellcode — Dokumentation lebt in Spiegeldateien
Verbindliche Source-of-Truth-Hierarchie überschreibt Agenten-Standardannahmen
Koordiniert den TASKS / PENDING / console.md Ablaufzyklus

md/README.md

Modell · Zuerst denken

Mentales Plattformmodell: JSON-Objektspeicher + Workflow-Engine.

Mentales Modell: JSON object storage + workflow (txn → state/status)
3 Architekturebenen: access, config, app
8 Design-Doktrinen: Jedes Feature muss hineinpassen; Widersprüche sind Design-Bugs
Entscheidet, ob ein Task ein Config-INSERT oder Codeänderungen erfordert

dbdict → Entity → Controller → Facade

Struktur · Level 0–3

Strikte Abwärtspriorität: Bei Konflikten gewinnt stets die tiefere Ebene.

Bei Diskrepanzen gewinnt die tiefere Schicht: Die Datenbank ist die oberste Wahrheit
dbdict/<schema>/<table>.sql inkl. GRANT UPDATE ist Level 0 Basis
Facade kapselt Transaktionen; Controller parst Formulare und delegiert
Jdbc erweitert ORM direkt ohne überflüssige Proxy- oder Processor-Schichten

Skills Suite

Ausführung · Phasenweise

Spezialisierte Fähigkeiten, die schrittweise im Workflow aufgerufen werden.

secure-tdd: Orchestrator zur Prüfung von Trust Boundaries und AuthN/Z
write-test (RED): Schreibt Specs; sbt testOnly muss initial fehlschlagen
owasp-coding + iso-27001 (GREEN): Garantiert konforme Sicherheitsstandards
mvc-skill (Schichten), scala-doc (Spiegel), antigravity (Übersetzung)

Doc Mirror & Externe Verträge

Doku · Synchronisiert

Dokumentation wird atomar im selben Changeset wie der Code aktualisiert.

Doc Mirror: app/x/Foo.scala ↔ md/app/x/Foo.md vor Änderung lesen
DocMirrorSpec schlägt fehl bei Code-Kommentaren oder verwaisten Überschriften
../nocode-api/SKILL.md: API-Vertrag für externe Agenten im getrennten Repo
Endpoint-Änderungen müssen Vertrag und Implementierung zeitgleich aktualisieren

TASKS / PENDING & console.md

Warteschlange · Audit

FIFO-Aufgabenverwaltung und lückenlose Iterations-Protokollierung.

TASKS.md: Von oben nach unten abarbeiten, ✅ setzen, Eintrag in ## LOG
PENDING.md: Gesperrtes Backlog; unveränderlicher Kontext
console.md: Vollständige Dokumentation (Aktion, Grund, Befehle, Metriken, Fehler)
Neuester Eintrag steht stets ganz oben; Terminal gibt kompakte Zusammenfassung aus

7-stufiger sequentieller Ausführungsablauf

Prozesskette

SCHRITT 01 Kontext laden

AGENTS.md + MEMORY.md laden. Nicht-englische Prompts mit antigravity übersetzen.

SCHRITT 02 Task wählen

TASKS.md ## TODO oberste Aufgabe wählen. Widerspruchsfreiheit zu PENDING.md prüfen.

SCHRITT 03 Modellabgleich

Gegen 8 Design-Doktrinen abgleichen. Entscheiden: Config INSERT vs. Code.

SCHRITT 04 TDD-Entscheidung

System-/Codeänderung = Spec Pflicht. Reines Artefakt (doc/JSON) = keine Spec.

SCHRITT 05 Red / Green / Refactor

secure-tdd ausführen. Fehlschlagende Spec (Red), Implementierung (Green), Bereinigung.

SCHRITT 06 Doku-Spiegelung

md/app/ Doku-Spiegel und SKILL.md im selben Commit wie den Code synchronisieren.

SCHRITT 07 Abschluss & Audit

✅ abhaken, in LOG & console.md eintragen, Terminal-Bericht ausgeben, nächsten Task holen.

AGENTS.md × Skills: Task Flow

AGENTS.md × Skills: วงจรทำงาน

AGENTS.md × Skills: 任务工作流

AGENTS.md × Skills: タスクフロー

AGENTS.md × Skills: Task Flow

AGENTS.md

md/README.md

dbdict → Entity → Controller → Facade

Skills Suite

Doc Mirror & API Contracts

TASKS / PENDING & console.md

7-Step Sequential Execution Flow

AGENTS.md

md/README.md

dbdict → Entity → Controller → Facade

Skills

Doc mirror & สัญญาภายนอก

TASKS / PENDING & console.md

สรุป 7 ขั้นตอนการทำงานทีละสเต็ป

AGENTS.md

md/README.md

dbdict → Entity → Controller → Facade

Skills 工具集

Doc Mirror 与 API 契约

TASKS / PENDING 与 console.md

7 步工作流执行阶段详解

AGENTS.md

md/README.md

dbdict → Entity → Controller → Facade

Skills スイート

Doc Mirror & 外部規約

TASKS / PENDING & console.md

7段階の実行パイプラインまとめ

AGENTS.md

md/README.md

dbdict → Entity → Controller → Facade

Skills Suite

Doc Mirror & Externe Verträge

TASKS / PENDING & console.md

7-stufiger sequentieller Ausführungsablauf