17a627a981
Address critical data visibility issues for Event Files and enhance frontend documentation.
This commit resolves the persistent problem where top-level hosted file convenience fields
(e.g., , , ) were
returning as in V3 Event File API responses, even when .
Key changes include:
- Refactored Pydantic model:
- Removed redundant definitions from top-level hosted file convenience fields,
allowing direct mapping from SQL view columns.
- Simplified to focus solely on conditionally loading the nested
object, as top-level fields are now populated directly by Pydantic
from the view.
- Added comprehensive comments to clarify data flow, Pydantic's behavior, and the
expected origin of these convenience fields from SQL views.
- Updated :
- Introduced a new section detailing how to retrieve Event File data, including the
use of to get both top-level convenience fields and a nested
object.
- Clarified all ID references as random string IDs.
- Renumbered the troubleshooting section.
- Copied updated guide to .
- Continued ID Vision compliance audit, ensuring consistent handling of random string IDs
across various core and event models (Account, Address, Contact, DataStore, Event Badge Template).
- Consolidated ID Vision E2E tests and updated related documentation.
- Minor updates to and
to support Event File data retrieval with .
36 lines
1.9 KiB
Markdown
36 lines
1.9 KiB
Markdown
# Aether Development SOP (Backend)
|
|
> **Version:** 1.0 (2026-02-11)
|
|
> **Location:** documentation/GUIDE__DEVELOPMENT.md
|
|
|
|
## 1. 🛡️ Verification (The "Test-First" Mandate)
|
|
**Rule:** No code is to be committed unless it has passed local verification. Skipping this is a violation of the Aether Dev Protocol.
|
|
|
|
### Required Checks:
|
|
1. **Syntax Validation:** `python3 -m py_compile <file_path>`
|
|
2. **Linting/Style:** `flake8 <file_path>`
|
|
3. **Pydantic Validation:** If changing models, verify with `app/models/` scripts.
|
|
4. **Service Health:** Restart the service and check logs:
|
|
- `docker restart aether_container_env-ae_api-2`
|
|
- `tail -n 50 ../aether_container_env/logs/ae_api/aether_api.log`
|
|
|
|
## 2. 📝 Commit & Sync Policy
|
|
- **Atomic Commits:** One feature or one bug fix per commit. Do not batch unrelated changes.
|
|
- **Verification Log:** Mention the verification steps taken in your work log (`ae_log_work`).
|
|
- **Safety:** Use `~/tmp/gemini_trash` for removals; never use `rm` directly on source files.
|
|
|
|
## 3. 🤝 The Handshake (Coordination)
|
|
You are not working in a vacuum. You MUST coordinate with the Frontend Agent.
|
|
|
|
### Mandatory Messaging Triggers:
|
|
- **API Changes:** When changing an endpoint signature, payload, or ID format.
|
|
- **Bugs:** When discovering a cross-stack issue.
|
|
- **Status:** Update your shared Journal in `~/agents_sync/aether/journals/` after significant milestones.
|
|
|
|
**Tool:** Use the `message` tool to communicate with the Frontend Agent.
|
|
|
|
## 🧠 Continuity
|
|
Before starting work:
|
|
1. Read `~/agents_sync/README.md` to understand the fleet status and cross-agent tasks.
|
|
2. Check `README.md` in the project root for technical specs.
|
|
3. Review your local `documentation/AGENT_TODO.md` for active tasks.
|
|
4. You must be able to explain what needs to be done and why before you start coding. This is important, as it demonstrates understanding and ensures alignment with project goals. |