| name | yao-geoflow-cli |
| description | Use when operating an existing GEOFlow 2.1+ system from CLI, API v1, or authenticated admin web for catalog/material/task/job/article operations, enterprise knowledge, growth-center leads, distribution, analytics, URL import, theme editor, frontend-capability sync, system updates, settings, tokens, users, or preflight. Do not use for implementation, schema changes, direct DB edits, frontend design, or invented API routes. |
Yao GEOFlow Operations
Operate a running GEOFlow instance. Prefer supported bin/geoflow, then API v1 for exposed content operations, then authenticated admin web for management workflows absent from API v1.
Boundary
- Owns operational CLI/API/admin work, CSRF/session handling, idempotency, readback verification, high-risk confirmation, and secret/personal-data redaction.
- Excludes product-code edits, migrations, direct SQL, frontend design, route invention, auth bypass, and secret exposure.
- Use
yao-geoflow-design for homepage/design payload planning.
Checks
- Confirm
artisan or bin/geoflow.
- Run
scripts/geoflow_preflight.sh "<workspace>" [config] [checks] before first mutation.
- Inspect CLI help,
routes/api.php, or php artisan route:list before choosing a surface.
- API fallback uses bearer auth, JSON,
Accept: application/json, and X-Idempotency-Key.
- Admin web reads the target page first, keeps CSRF/cookies, posts the owning route, then verifies readback.
- Require explicit target/action for destructive, secret-revealing, package-download, theme-publish, bulk sync, lead export, or update-center operations.
References
operation-boundary.md, command-map.md, laravel-api-v1-docker.md, geoflow-current-capability-map.md, trigger_cases.json, upgrade report.
