Every managed user repository gets a .agentappflow/ directory at the repo root. This directory is the project-local contract between AgentAppFlow and AI coding agents such as Codex and Claude Code.
The goal is to keep canonical project memory and framework rules visible inside the repo while allowing derived indexes and caches to remain local implementation details.
.agentappflow/
project.yaml
rules/
templates/
sessions/
retros/
proposals/
cache/
project.yaml: project identity, stack, goals, enabled agent tools, and policy settingsrules/: generated working rules and project guardrailstemplates/: task, review, onboarding, and retrospective templatessessions/: human-readable session summaries and transcriptsretros/: post-task Q&A, outcomes, and lessons learnedproposals/: pending or accepted framework changescache/: derived local indexes such as SQLite, embeddings, or search artifacts
Initial required fields:
project_type: ios_app
platforms:
- macos
- ios
tech_stack:
ui: swift
orchestration: python
execution: rust
agent_tools:
- codex
- claude_code
approval_mode: propose
memory_mode: local_repo
improvement_mode: proposeCore fields:
project_typeplatformstech_stackagent_toolsapproval_modememory_modeimprovement_mode
Canonical state should stay human-readable and live in version-controlled repo paths when appropriate:
project.yaml- rules
- templates
- session summaries
- retrospectives
- proposals
Derived state belongs in .agentappflow/cache/ and should usually be gitignored:
- SQLite indexes
- embeddings
- retrieval caches
- temporary execution metadata
The framework should generate thin root-level adapter files:
AGENTS.mdfor Codex-compatible toolsCLAUDE.mdfor Claude Code and similar agent runtimes
These files should point agents into .agentappflow/ rather than duplicating all framework content at repo root.
observe: do not activate framework updatespropose: create a proposal and wait for user approvalauto: activate framework-only changes automatically
auto must be constrained to framework-owned paths and may not silently modify unrelated user source code.
After each task, the framework should capture:
- what succeeded
- what failed or created friction
- what should change in the framework
- confidence level
- evidence or examples from the finished task
That output becomes the basis for future framework proposals and project specialization.