delete/update_server
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
update_server/docs/agents/WORKFLOW.md
delete b15b95781c init
2026-06-10 20:51:17 +03:00

14 KiB
Raw Blame History

AI Agent Workflow Runbook

1. Purpose

This document defines how to implement the update server with sequential AI agents.

The workflow is designed for:

  • one human operator who launches agents one by one;
  • one implementation agent per stage;
  • one validation agent after each stage;
  • file-based handoff instead of direct agent-to-agent chat.

2. Source Of Truth

Every implementation agent must read these files before starting:

  • /Users/delete/projects/update_server/PRODUCT_SPEC.md
  • /Users/delete/projects/update_server/IMPLEMENTATION_PLAN.md
  • /Users/delete/projects/update_server/DEVELOPMENT_WORKFLOW.md
  • /Users/delete/projects/update_server/docs/agents/WORKFLOW.md

Every agent must also read the latest handoff and validation files if they exist.

3. Fixed Technical Decisions

These decisions are considered fixed unless the human operator explicitly changes them.

  • Language: Go
  • Router: chi
  • Database: SQLite
  • HTML strategy: server-rendered HTML templates
  • Artifact storage: local filesystem
  • Deployment shape: app container behind Caddy or Nginx
  • Web auth: session-based authentication
  • Client auth: Authorization: Bearer <api_key>
  • API key access modes:
    • all_projects
    • project_allow_list
    • project_deny_list
    • tag_allow_list
    • tag_deny_list
  • One API key must use exactly one scope mode at a time
  • Projects support tags from day one
  • Security is mandatory, not optional

4. Shared Workspace Rules

All code lives in the main repository.

Agents should use these implementation paths:

  • /Users/delete/projects/update_server/cmd/server
  • /Users/delete/projects/update_server/internal
  • /Users/delete/projects/update_server/web
  • /Users/delete/projects/update_server/migrations

Agents must use these coordination paths:

  • handoffs: /Users/delete/projects/update_server/docs/agents/handoffs
  • validations: /Users/delete/projects/update_server/docs/agents/validation

If an agent needs to communicate something to the next agent, it must do so through:

  • code changes;
  • a handoff file;
  • updates to spec or implementation docs if architecture changed.

Agents should not rely on hidden memory or previous chat state.

5. Handoff Protocol

After finishing work, every implementation agent must create a handoff file:

  • naming format: NN-agent-name.md
  • example: 01-foundation.md

Each handoff file should be saved in:

  • /Users/delete/projects/update_server/docs/agents/handoffs

The handoff file must include:

  • scope of work;
  • files changed;
  • migrations added or changed;
  • endpoints added or changed;
  • tests or commands run;
  • known limitations;
  • exact next recommended step.

Use this template:

  • /Users/delete/projects/update_server/docs/agents/HANDOFF_TEMPLATE.md

6. Validation Protocol

After each implementation agent finishes, run a validation agent before moving to the next stage.

The validation agent should:

  • read the current agent section in this file;
  • read the latest handoff file;
  • inspect code changes;
  • run relevant tests or checks;
  • produce a validation report.

Validation files should be saved in:

  • /Users/delete/projects/update_server/docs/agents/validation

Use this template:

  • /Users/delete/projects/update_server/docs/agents/VALIDATION_TEMPLATE.md

Validation result must end in one of these statuses:

  • APPROVED
  • CHANGES_REQUIRED

Do not launch the next implementation agent until the previous stage is APPROVED.

7. Agent Count

Recommended sequence:

  • 7 implementation agents
  • 1 validation agent role used after every stage

The validation agent can be the same AI system reused every time.

8. Agent 01 - Foundation

Mission

Set up the repository skeleton and the minimum runnable Go application.

Ownership

This agent owns:

  • Go module initialization
  • basic app boot
  • config loading
  • HTTP router setup
  • health endpoint
  • base middleware wiring
  • template bootstrapping
  • initial developer commands

Deliverables

This agent must produce:

  • runnable server entrypoint
  • config package
  • base router with route groups
  • health endpoint
  • base HTML layout structure
  • initial project structure under cmd, internal, and web

Out Of Scope

This agent must not implement:

  • business logic
  • database schema
  • authentication flows
  • release upload
  • API keys

Acceptance Criteria

  • the app starts successfully;
  • a health endpoint responds;
  • the code structure matches the implementation plan;
  • the project is ready for migrations and feature modules.

9. Agent 02 - Database And Migrations

Mission

Create the data model, migrations, and database access foundation.

Ownership

This agent owns:

  • migration setup
  • database connection layer
  • schema design
  • repository or query layer foundation

Deliverables

This agent must implement tables for:

  • users
  • projects
  • tags
  • project_tags
  • releases
  • api_keys
  • api_key_project_access
  • api_key_tag_access
  • sessions if needed
  • audit_logs if included in the first pass

Out Of Scope

This agent must not implement:

  • login UI
  • upload endpoints
  • full business workflows

Acceptance Criteria

  • migrations can be applied cleanly;
  • schema matches the spec;
  • access tables support project and tag based key scopes;
  • database layer is ready for the next agents.

10. Agent 03 - Authentication And Admin Sessions

Mission

Implement admin authentication and session management.

Ownership

This agent owns:

  • admin bootstrap user creation
  • password hashing
  • login and logout flow
  • session middleware
  • role checks foundation

Deliverables

This agent must produce:

  • login form and login handler
  • session creation and invalidation
  • protected admin route group
  • admin bootstrap from environment or setup logic

Out Of Scope

This agent must not implement:

  • project management
  • release upload
  • API key logic

Acceptance Criteria

  • admin can log in and log out;
  • protected routes are actually protected;
  • passwords are hashed securely;
  • session handling works reliably.

11. Agent 04 - Projects, Tags, And Releases

Mission

Implement core product data management: projects, project tags, and release upload metadata flow.

Ownership

This agent owns:

  • project CRUD
  • tag CRUD
  • attach or detach tags from projects
  • release metadata handling
  • artifact storage abstraction
  • upload flow and checksum generation

Deliverables

This agent must produce:

  • project create, edit, list, archive flow
  • tag create, edit, list flow
  • project-tag assignment
  • release upload service
  • artifact persistence on disk
  • checksum capture

Out Of Scope

This agent must not implement:

  • API key access logic
  • external client update endpoints

Acceptance Criteria

  • admin can manage projects and tags;
  • admin can upload a release to a project;
  • release metadata is stored in the database;
  • artifact files are stored outside the public web root.

12. Agent 05 - API Keys And Access Control

Mission

Implement API key generation, hashing, permissions, and scope evaluation.

Ownership

This agent owns:

  • secure API key generation
  • API key hashing and lookup
  • permission flags
  • access scope evaluation
  • project allow or deny list rules
  • tag allow or deny list rules

Deliverables

This agent must produce:

  • API key creation flow
  • one-time key reveal behavior
  • key activation and revocation
  • permission middleware for API key routes
  • project and tag access resolution logic

Out Of Scope

This agent must not implement:

  • final UI polish
  • deployment hardening

Acceptance Criteria

  • API keys are stored hashed;
  • only authorized projects are visible to a given key;
  • allow-list and deny-list logic works for projects and tags;
  • disabled or expired keys are rejected.

13. Agent 06 - Client API And Admin UI

Mission

Implement the usable product experience for admins and client applications.

Ownership

This agent owns:

  • admin pages for projects, tags, releases, and API keys
  • client-facing update endpoints
  • latest-release lookup
  • release metadata endpoint
  • authenticated download endpoint

Deliverables

This agent must produce:

  • admin pages that cover the main flows
  • client endpoint to list accessible projects
  • client endpoint to get latest release metadata
  • client endpoint to download a release

Out Of Scope

This agent must not implement:

  • deep security hardening beyond local route protection
  • production reverse proxy setup

Acceptance Criteria

  • an admin can complete the full product flow from the browser;
  • a client can authenticate with a bearer API key;
  • a client can discover and download only authorized updates.

14. Agent 07 - Security And Deployment Hardening

Mission

Make the system safe and deployable on an internet-facing server.

Ownership

This agent owns:

  • security headers
  • rate limiting
  • request timeouts
  • CSRF finishing pass
  • safer cookie settings
  • reverse proxy examples
  • Docker and deployment finishing pass
  • backup and operational notes

Deliverables

This agent must produce:

  • hardened HTTP server settings
  • production-ready container setup
  • Caddy or Nginx example configuration
  • deployment notes for Proxmox
  • security review fixes that fit the current architecture

Out Of Scope

This agent must not redesign the product or data model unless a critical security issue requires it.

Acceptance Criteria

  • the service is ready to run behind HTTPS;
  • admin and client traffic have sane security defaults;
  • artifacts are not directly exposed;
  • deployment instructions are complete enough for first production rollout.

15. Validation Agent Role

Mission

Review each completed stage before the next implementation agent starts.

Required Checks

The validation agent should verify:

  • scope completion;
  • obvious regressions;
  • schema or route mismatches;
  • missing tests;
  • unsafe behavior;
  • contradictions with the spec.

Output

The validation agent must write one validation file per stage and finish with:

  • APPROVED
  • or CHANGES_REQUIRED

16. Operator Guide For Human User

Этот раздел специально для тебя, на русском.

Общая схема запуска

Запускаешь агентов строго по порядку:

  1. Agent 01 - Foundation
  2. Validator
  3. Agent 02 - Database And Migrations
  4. Validator
  5. Agent 03 - Authentication And Admin Sessions
  6. Validator
  7. Agent 04 - Projects, Tags, And Releases
  8. Validator
  9. Agent 05 - API Keys And Access Control
  10. Validator
  11. Agent 06 - Client API And Admin UI
  12. Validator
  13. Agent 07 - Security And Deployment Hardening
  14. Final Validator

Как запускать каждый этап

Для каждого нового агента даёшь ему один и тот же базовый контекст:

  • прочитать PRODUCT_SPEC.md
  • прочитать IMPLEMENTATION_PLAN.md
  • прочитать DEVELOPMENT_WORKFLOW.md
  • прочитать docs/agents/WORKFLOW.md
  • прочитать последний handoff-файл
  • прочитать последний validation-файл, если он есть

После этого говоришь агенту работать только в рамках его секции из этого runbook.

Что требовать от каждого агента

После завершения этапа агент обязан:

  • внести код;
  • если нужно, обновить документацию;
  • создать handoff-файл в docs/agents/handoffs;
  • перечислить, что сделано;
  • перечислить, что не сделано;
  • указать, что должен делать следующий агент.

Когда запускать валидатора

Валидатора запускаешь после каждого агента.

Ему даёшь задачу:

  • прочитать соответствующую секцию агента из docs/agents/WORKFLOW.md;
  • прочитать свежий handoff;
  • проверить код;
  • проверить, не нарушена ли спецификация;
  • выдать APPROVED или CHANGES_REQUIRED;
  • сохранить отчёт в docs/agents/validation.

Если валидатор нашёл проблемы

Если статус CHANGES_REQUIRED, то:

  1. не переходишь к следующему агенту;
  2. запускаешь того же самого агента повторно;
  3. даёшь ему его прошлый handoff и validation report;
  4. просишь закрыть замечания;
  5. снова запускаешь валидатора.

Когда использовать меня как валидатора

Меня лучше использовать:

  • после каждого крупного этапа;
  • перед миграциями базы;
  • перед этапом security hardening;
  • перед первым Docker/deploy;
  • перед выкладкой на Proxmox.

Практически удобный режим

Самый удобный режим для тебя такой:

  1. локально на Mac запускаешь первого агента;
  2. проверяешь, что handoff-файл создался;
  3. зовёшь меня как валидатора;
  4. после APPROVED запускаешь следующего агента;
  5. когда дойдёшь до конца, только потом собираешь контейнер и переносишь на Proxmox.

Главный принцип

Следующий агент никогда не стартует без handoff от прошлого и без validation report.

Это защитит тебя от хаоса, повторной работы и скрытых поломок между этапами.