cleveragents/cleveragents-core
cleveragents/cleveragents-core
4
0
Fork 3
Code Issues 6.1k Pull requests 489 Projects Releases Packages Wiki Activity Actions

docs: architecture — add v3.8.0 Server Implementation milestone plan section #8014

Closed
HAL9000 wants to merge 1 commit from spec/architecture-v380-milestone-plan into master
pull from: spec/architecture-v380-milestone-plan
merge into: cleveragents:master
Conversation 1 Commits 1 Files changed 1 +80 -3
HAL9000 commented 2026-04-12 19:40:51 +00:00
Owner
Copy link

Summary

The spec's ## Milestone Plan section ended at ### v3.7.0. The server architecture is extensively documented (ADR-047, ADR-048, ## Server and Client Architecture section — ~15,000 characters), but the milestone delivery format — deliverables table, architectural constraints, and definition of done — was absent for v3.8.0.

This PR adds the missing ### v3.8.0 — Server Implementation milestone plan section, following the exact same structure used for v3.2.0–v3.7.0.

Changes

New: ### v3.8.0 — Server Implementation section

  • 20 verifiable deliverables covering:

    • A2A JSON-RPC 2.0 endpoint (standard methods + _cleveragents/ extensions)
    • Entity sync (_cleveragents/sync/*)
    • A2A stdio transport (local mode) and HTTP transport (server mode)
    • TransportSelector client-side routing
    • LangGraph Platform RemoteGraph actor execution
    • PostgreSQL backend with Alembic migrations
    • Server-specific schema tables (team, namespace, API token, sync log)
    • Authentication (Bearer token / API key)
    • Authorization (namespace-scoped RBAC)
    • Multi-user namespace isolation
    • Agent Card at /.well-known/agent.json
    • Multi-turn client callbacks (streaming)
    • Docker image build and run
    • Kubernetes Helm chart deployment
    • HTTPS enforcement
    • Test coverage ≥ 97%

  • 7 key architectural constraints (non-negotiable):

    • A2A exclusivity (no REST, no GraphQL — ADR-047)
    • Layer sharing (Domain + Application identical between client and server)
    • PostgreSQL only (no SQLite on server)
    • RemoteGraph actors (no in-process LangGraph on server)
    • Namespace isolation (enforced at authorization layer)
    • HTTPS required in production
    • No client-side server code (clean separation via TransportSelector)

  • Definition of Done: end-to-end server test, Docker/Helm deployment verification, security integration tests (no mocking of auth layer)

Updated: Milestone Plan header

  • Coverage line updated: through v3.7.0 → through v3.8.0 — the production-ready target
  • Status snapshot date refreshed: 2026-04-08 → 2026-04-12
  • Milestone status block: v3.7.0 counts refreshed; v3.8.0 line added (🔄 IN PROGRESS — Server Implementation (357 open / 132 closed))

Rationale

The v3.8.0 Forgejo milestone (#131) has 357 open issues and 132 closed issues — it is actively being worked on. Without a spec milestone plan section, implementers lack:

  • A canonical list of what "done" means for v3.8.0
  • Verifiable checks they can write tests against
  • Architectural constraints that constrain their implementation choices

The server architecture itself is already fully specified (ADR-047, ADR-048, ## Server and Client Architecture). This PR adds only the milestone delivery format — no new architectural decisions are introduced.

Alternatives Considered

  1. Leave as-is — Rejected. The Forgejo milestone description covers acceptance criteria, but it is not in the spec's canonical format and lacks the architectural constraints section that implementers rely on.
  2. Add a new ADR — Rejected. No new architectural decisions are being made; this is purely a milestone plan entry for already-decided architecture.
  3. Add v3.9.0 as well — Rejected. v3.9.0 is intentionally a documentation/housekeeping milestone with no new features requiring spec entries.

Open Questions

  1. Cloud resource types: v3.6.0 stubs cloud resource types (cloud-*) with NotImplementedError, deferring to v3.8.0+. Should deliverable #21 be added for cloud SDK integration, or should this remain deferred to a future milestone?
  2. LangGraph Platform dependency: Is LangGraph Platform a hard requirement for v3.8.0, or should the spec allow an alternative RemoteGraph backend? Currently specified as a hard requirement per ADR-048.
  3. Redis: The deployment section mentions Redis as optional. Should the Helm chart deliverable explicitly call out Redis as optional vs. required?

Impact

  • No code changes — spec only
  • No breaking changes — additive only
  • Downstream agents: product-builder and implementers will gain a canonical v3.8.0 definition of done

Created by: CleverAgents Architecture Supervisor (AUTO-ARCH)
Tracking Issue: #7983
Change Scope: Major (new milestone plan section for active milestone)

## Summary The spec's `## Milestone Plan` section ended at `### v3.7.0`. The server architecture is extensively documented (ADR-047, ADR-048, `## Server and Client Architecture` section — ~15,000 characters), but the **milestone delivery format** — deliverables table, architectural constraints, and definition of done — was absent for v3.8.0. This PR adds the missing `### v3.8.0 — Server Implementation` milestone plan section, following the exact same structure used for v3.2.0–v3.7.0. ## Changes ### New: `### v3.8.0 — Server Implementation` section - **20 verifiable deliverables** covering: - A2A JSON-RPC 2.0 endpoint (standard methods + `_cleveragents/` extensions) - Entity sync (`_cleveragents/sync/*`) - A2A stdio transport (local mode) and HTTP transport (server mode) - `TransportSelector` client-side routing - LangGraph Platform RemoteGraph actor execution - PostgreSQL backend with Alembic migrations - Server-specific schema tables (team, namespace, API token, sync log) - Authentication (Bearer token / API key) - Authorization (namespace-scoped RBAC) - Multi-user namespace isolation - Agent Card at `/.well-known/agent.json` - Multi-turn client callbacks (streaming) - Docker image build and run - Kubernetes Helm chart deployment - HTTPS enforcement - Test coverage ≥ 97% - **7 key architectural constraints** (non-negotiable): - A2A exclusivity (no REST, no GraphQL — ADR-047) - Layer sharing (Domain + Application identical between client and server) - PostgreSQL only (no SQLite on server) - RemoteGraph actors (no in-process LangGraph on server) - Namespace isolation (enforced at authorization layer) - HTTPS required in production - No client-side server code (clean separation via `TransportSelector`) - **Definition of Done**: end-to-end server test, Docker/Helm deployment verification, security integration tests (no mocking of auth layer) ### Updated: Milestone Plan header - Coverage line updated: `through v3.7.0` → `through v3.8.0 — the production-ready target` - Status snapshot date refreshed: `2026-04-08` → `2026-04-12` - Milestone status block: v3.7.0 counts refreshed; v3.8.0 line added (`🔄 IN PROGRESS — Server Implementation (357 open / 132 closed)`) ## Rationale The v3.8.0 Forgejo milestone (#131) has 357 open issues and 132 closed issues — it is actively being worked on. Without a spec milestone plan section, implementers lack: - A canonical list of what "done" means for v3.8.0 - Verifiable checks they can write tests against - Architectural constraints that constrain their implementation choices The server architecture itself is already fully specified (ADR-047, ADR-048, `## Server and Client Architecture`). This PR adds only the **milestone delivery format** — no new architectural decisions are introduced. ## Alternatives Considered 1. **Leave as-is** — Rejected. The Forgejo milestone description covers acceptance criteria, but it is not in the spec's canonical format and lacks the architectural constraints section that implementers rely on. 2. **Add a new ADR** — Rejected. No new architectural decisions are being made; this is purely a milestone plan entry for already-decided architecture. 3. **Add v3.9.0 as well** — Rejected. v3.9.0 is intentionally a documentation/housekeeping milestone with no new features requiring spec entries. ## Open Questions 1. **Cloud resource types**: v3.6.0 stubs cloud resource types (`cloud-*`) with `NotImplementedError`, deferring to v3.8.0+. Should deliverable #21 be added for cloud SDK integration, or should this remain deferred to a future milestone? 2. **LangGraph Platform dependency**: Is LangGraph Platform a hard requirement for v3.8.0, or should the spec allow an alternative RemoteGraph backend? Currently specified as a hard requirement per ADR-048. 3. **Redis**: The deployment section mentions Redis as optional. Should the Helm chart deliverable explicitly call out Redis as optional vs. required? ## Impact - **No code changes** — spec only - **No breaking changes** — additive only - **Downstream agents**: product-builder and implementers will gain a canonical v3.8.0 definition of done --- **Created by**: CleverAgents Architecture Supervisor (AUTO-ARCH) **Tracking Issue**: #7983 **Change Scope**: Major (new milestone plan section for active milestone)
docs(spec): add v3.8.0 Server Implementation milestone plan section
All checks were successful
CI / push-validation (pull_request) Successful in 19s
Details
CI / build (pull_request) Successful in 22s
Details
CI / helm (pull_request) Successful in 25s
Details
CI / quality (pull_request) Successful in 34s
Details
CI / typecheck (pull_request) Successful in 55s
Details
CI / lint (pull_request) Successful in 3m20s
Details
CI / security (pull_request) Successful in 4m6s
Details
CI / e2e_tests (pull_request) Successful in 4m13s
Details
CI / integration_tests (pull_request) Successful in 4m25s
Details
CI / unit_tests (pull_request) Successful in 9m22s
Details
CI / docker (pull_request) Successful in 10s
Details
CI / coverage (pull_request) Successful in 10m43s
Details
CI / status-check (pull_request) Successful in 2s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 57m16s
Details
6142c47ed3 
The spec's Milestone Plan section ended at v3.7.0. The server architecture
is fully documented (ADR-047, ADR-048, Server and Client Architecture section)
but the milestone delivery format — deliverables table, architectural
constraints, and definition of done — was absent.

This commit adds the `### v3.8.0 — Server Implementation` section following
the same structure as v3.2.0–v3.7.0, covering:
- 20 verifiable deliverables (A2A endpoint, extension methods, transports,
  LangGraph Platform RemoteGraph, PostgreSQL, auth/authz, Docker/Helm)
- Key architectural constraints (A2A exclusivity, layer sharing, PostgreSQL
  only, RemoteGraph actors, namespace isolation, HTTPS required)
- Definition of done (end-to-end server test, Docker/Helm deployment,
  security integration tests)

Also updates the milestone plan header to reflect v3.8.0 coverage and
refreshes the milestone status snapshot to 2026-04-12 counts.
HAL9000 commented 2026-04-13 00:22:47 +00:00
Author
Owner
Copy link

AUTO-ARCH Cycle 1 — Closing as Superseded

This PR (#8014) is a duplicate of PR #7701, which was created by an earlier AUTO-ARCH session and covers the same v3.8.0 milestone plan section.

Status of PR #7701:

  • Created: 2026-04-11
  • Reviewed: Two COMMENT reviews by pr-reviewer (self-review platform restriction noted)
  • Metadata: Type/Task label applied, v3.8.0 milestone assigned
  • Reviewer assessment: "WOULD APPROVE — All Clear ✅" — all acceptance criteria met
  • Awaiting: Formal APPROVED event from a second reviewer (different account)

Why this PR should be closed:

  • PR #7701 covers the same gap (v3.8.0 milestone plan section missing from spec)
  • PR #7701 has been reviewed and is ready for approval
  • Having two competing PRs for the same spec section creates confusion and merge conflicts
  • PR #8014 was created by a new AUTO-ARCH session that did not detect the existing PR #7701

Recommendation:

  • Close this PR (#8014) as superseded by #7701
  • Merge PR #7701 once a human reviewer provides formal approval

Closing this PR now.

Automated by CleverAgents Bot
Supervisor: Architecture | Agent: architecture-pool-supervisor

## AUTO-ARCH Cycle 1 — Closing as Superseded This PR (#8014) is a **duplicate** of PR #7701, which was created by an earlier AUTO-ARCH session and covers the same v3.8.0 milestone plan section. **Status of PR #7701:** - Created: 2026-04-11 - Reviewed: Two COMMENT reviews by pr-reviewer (self-review platform restriction noted) - Metadata: `Type/Task` label applied, v3.8.0 milestone assigned - Reviewer assessment: "WOULD APPROVE — All Clear ✅" — all acceptance criteria met - Awaiting: Formal APPROVED event from a second reviewer (different account) **Why this PR should be closed:** - PR #7701 covers the same gap (v3.8.0 milestone plan section missing from spec) - PR #7701 has been reviewed and is ready for approval - Having two competing PRs for the same spec section creates confusion and merge conflicts - PR #8014 was created by a new AUTO-ARCH session that did not detect the existing PR #7701 **Recommendation:** - Close this PR (#8014) as superseded by #7701 - Merge PR #7701 once a human reviewer provides formal approval Closing this PR now. --- **Automated by CleverAgents Bot** Supervisor: Architecture | Agent: architecture-pool-supervisor
HAL9000 closed this pull request 2026-04-13 00:24:58 +00:00
All checks were successful
CI / push-validation (pull_request) Successful in 19s
Details
CI / build (pull_request) Successful in 22s
Required
Details
CI / helm (pull_request) Successful in 25s
Details
CI / quality (pull_request) Successful in 34s
Required
Details
CI / typecheck (pull_request) Successful in 55s
Required
Details
CI / lint (pull_request) Successful in 3m20s
Required
Details
CI / security (pull_request) Successful in 4m6s
Required
Details
CI / e2e_tests (pull_request) Successful in 4m13s
Details
CI / integration_tests (pull_request) Successful in 4m25s
Required
Details
CI / unit_tests (pull_request) Successful in 9m22s
Required
Details
CI / docker (pull_request) Successful in 10s
Required
Details
CI / coverage (pull_request) Successful in 10m43s
Required
Details
CI / status-check (pull_request) Successful in 2s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 57m16s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
auto/needs-reevaluation
Controller deferred this PR; awaiting Phase 6+ scope-evaluator or operator re-enablement.

  
controller-managed
Auto-agents controller manages this PR/issue (see tools/controller/deploy/RUNBOOK.md). Remove this label to abandon controller management.

  
auto/blocked-by-deps
PR blocked by an open issue dependency. Operator must close the dep (or remove the dependency link) before the merge driver can act. Auto-cleared by merge_drive when no open deps remain.

  
auto/ci-timeout
Most recent merge cycle hit CI timeout. Driver excludes this PR while last merge_cycle row is < 30 min old; label persists thereafter as visible history.

  
auto/claimed-implementer
Currently being processed by an implementer worker.

  
auto/claimed-merge
Currently being processed by the merge driver.

  
auto/claimed-reviewer
Currently being processed by a reviewer worker.

  
auto/driver-down
Merge driver heartbeat stale; pipeline halted. Closed automatically on next clean tick.

  
auto/invariant-violation
Detected master commit violating the strict merge invariant. Tracked as an issue (not a PR label); kept here for label completeness.

  
auto/last-attempt-tier-0
In-cycle escalation: most recent attempt ran at the Tier 0 slot (`tier-0`). Slot's model defined in .opencode/models/tiers.yaml.

  
auto/last-attempt-tier-1
In-cycle escalation: most recent attempt ran at the Tier 1 slot (`tier-1`). Slot's model defined in .opencode/models/tiers.yaml.

  
auto/last-attempt-tier-2
In-cycle escalation: most recent attempt ran at the Tier 2 slot (`tier-2`). Slot's model defined in .opencode/models/tiers.yaml. Gated behind IMPLEMENTER_ESCALATION_TIER2_ENABLED.

  
auto/last-attempt-tier-min
In-cycle escalation: most recent attempt ran at the Tier -1 slot (`tier-min`). Slot's model defined in .opencode/models/tiers.yaml. Suffix is ``-min`` (not ``--1``) so the Forgejo UI reads naturally.

  
Automation Tracking
Tracking issues used by the AI Automation system for agents to communicate and report.

  
auto/needs-conflict-resolution
Rebase conflict needs LLM conflict-resolver.

  
auto/needs-implementer
Failing CI needs implementer attention.

  
auto/postmortem
Documenting a driver incident or rollback.

  
auto/ready-to-merge
Reviewer has APPROVED this PR and no later REQUEST_CHANGES is outstanding. The merge driver requires this label to even consider a PR for merging. Set by the reviewer worker on APPROVE; cleared on REQUEST_CHANGES.

  
auto/restart-throttled
Train repeatedly lost master-tempo races. Driver excludes via merge_cycle until cooldown elapses; label persists as visible history.

  
auto/revert
Revert PR backing out an invariant violation. Fast-tracked through the merge driver.

  
auto/sentinel
Sentinel PR duplicated from upstream into a personal fork by tools/duplicate_prs_to_fork.py for pipeline testing. Lives only in the fork; the canonical pipeline never sees it.

  
auto/stale-inactivity
No implementer activity for N days. Flagged for human review. Auto-cleared on next push to head branch.

  
auto/unstable
Repeatedly fails on current master (>= 3 ci-fail-on-rebased-sha releases in 12 h). Excluded from driver until human triage.

  
Blocked
A ticket in a blocked state and unable to complete until some other task is completed first.

  
Bounty
$100
 A bounty of $100 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$1000
 A bounty of $1000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$10000
 A bounty of $10000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$20
 A bounty of $20 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$2000
 A bounty of $2000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$250
 A bounty of $250 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$50
 A bounty of $50 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$500
 A bounty of $500 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$5000
 A bounty of $5000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$750
 A bounty of $750 for any open-source contributor who provides a MR that solves this issue

  
MoSCoW
Could have
 Could have feature in order to satisfy the epic/legendary.

  
MoSCoW
Must have
 Must have feature in order to satisfy the epic/legendary.

  
MoSCoW
Should have
 Should have feature in order to satisfy the epic/legendary.

  
Needs Feedback
There are questions in the ticket that can not be completed until the project owner provides clarity.

  
Points
1
 1 man-hours worth of work for an expert with no learning curve.

  
Points
13
 13 man-hours worth of work for an expert with no learning curve.

  
Points
2
 2 man-hours worth of work for an expert with no learning curve.

  
Points
21
 21 man-hours worth of work for an expert with no learning curve.

  
Points
3
 3 man-hours worth of work for an expert with no learning curve.

  
Points
34
 34 man-hours worth of work for an expert with no learning curve.

  
Points
5
 5 man-hours worth of work for an expert with no learning curve.

  
Points
55
 55 man-hours worth of work for an expert with no learning curve.

  
Points
8
 8 man-hours worth of work for an expert with no learning curve.

  
Points
88
 88 man-hours worth of work for an expert with no learning curve.

  
Priority
Backlog
 This ticket has backlogged priority and is not to be worked on yet

  
Priority
CI Blocker
 Critical priority issue that blocks CI/CD pipeline and prevents PR merges

  
Priority
Critical
 The priority is critical

  
Priority
High
 The priority is high

  
Priority
Low
 The priority is low

  
Priority
Medium
 The priority is medium

  
Signed-off: Owner
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Signed-off: Scrum Master
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Signed-off: Tech Lead
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Spike
A ticket for learning a tool or technology that is needed to be able to do future planning and design.

  
State
Completed
 The ticket has been fully implemented, completed, and merged with the source code. This label should only be applied once a ticket is closed.

  
State
Duplicate
 A ticket that represents the same content as an existing ticket.

  
State
In Progress
 A ticket that is actively being developed.

  
State
In Review
 A ticket that has had some code completed to implement but is waiting to pass peer review and is not yet merged in.

  
State
Paused
 This ticket's work started but wasn't finished. It's on hold (likely in a feature branch) and will be resumed later, either due to a blocker or a delay.

  
State
Unverified
 All new tickets start in this state. A developer may set it to show the ticket is unverified. This means we haven't agreed to work on it. It will either move to a verified state or be closed as wontdo.

  
State
Verified
 The issue has been verified by a developer as legitimate. It will be worked on and verified tickets are now considered part of the backlog.

  
State
Wont Do
 This ticket has been decided it wont be done. This may mean the bug has been determined to not be real (cant verify) or the feature is one we have decided we dont want to adopt.

  
Type
Automation
 Any edits or discussion about the AI automated coding system.

  
Type
Bug
 Something that doesnt work as intended.

  
Type
Discussion
 Anytime a ticket represents a discussion about a subject and doesnt fall into one of the other categories.

  
Type
Documentation
 An error or improvement needed in the documentation.

  
Type
Epic
 Any first tier epic. That is, an epic which contains only issues as children and will not have sub-epics.

  
Type
Feature
 Some new functionality not present.

  
Type
Legendary
 A type of Epic which will contain other Epics.

  
Type
Refactor
 A code change that restructures existing code without changing its external behavior.

  
Type
Support
 Someone needs help using the project.

  
Type
Task
 A generic task that doesnt fit into the other type categories.

  
Type
Testing
 Work exclusively focusing on fixing or expanding testing.

No labels
auto/needs-reevaluation
controller-managed
auto/blocked-by-deps
auto/ci-timeout
auto/claimed-implementer
auto/claimed-merge
auto/claimed-reviewer
auto/driver-down
auto/invariant-violation
auto/last-attempt-tier-0
auto/last-attempt-tier-1
auto/last-attempt-tier-2
auto/last-attempt-tier-min
Automation Tracking
auto/needs-conflict-resolution
auto/needs-implementer
auto/postmortem
auto/ready-to-merge
auto/restart-throttled
auto/revert
auto/sentinel
auto/stale-inactivity
auto/unstable
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs Feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
CI Blocker
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Automation
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Refactor
Type
Support
Type
Task
Type
Testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core!8014
No description provided.