Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 101 Pull Requests 10 Actions Packages Projects Releases Wiki Activity

Epic: certify safe multi-LLM execution through securely isolated remote MCP #955

New Issue
Open
opened 2026-07-28 02:49:51 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-28 02:49:51 -05:00
Owner
Copy Link
Copy Source

Coordination-only umbrella. This issue does not restate or duplicate the implementation scope of #887 or #929.

Summary

Two independent programs must both complete before unattended multi-client operation is safe: #887 (transactional author workflows for multiple LLM clients) and #929 (remote MCP deployment). Neither epic references the other, and neither owns the joint end state.

Goal supported: both — multi-LLM and secure isolation.

Problem

The two end states are coupled. Safe concurrency without credential isolation still leaves every workstation holding a Gitea token. Credential isolation without concurrency safety still serializes the fleet. Today nothing tracks the conjunction, and nothing prevents unattended scheduling from starting once only one half completes.

Current evidence

  • #887's completion gate names two clients and the author role only.
  • #929's completion gate names two clients across author, reviewer, and merger.
  • Neither epic names the other.
  • No roadmap-labelled issue links them. #820 is the control-plane architecture program, and #887 explicitly classes it as different scope. #75 and #10 are closed.

Scope

  • Link the canonical epics.
  • Own the joint completion definition.
  • Own the combined certification gate.
  • Track the cross-cutting canaries.

Non-goals

  • Implementing anything.
  • Re-specifying the children of #887 or #929.
  • Changing the role taxonomy or Gitea-side branch protection.

Dependencies

  • #887 — transactional author workflows safe for multiple LLM clients.
  • #929 — remote MCP deployment.
  • The concurrency canary, the credential-exfiltration canary, and the combined certification gate. Child issue numbers are linked in a follow-up roadmap summary comment on this issue.

Definition of done

Both end states below hold, both canaries pass, and the combined gate is enforced in code rather than by convention.

Multi-LLM end state

Multiple independent clients work simultaneously without identity reuse, repository crossover, lease theft, duplicate work, invalid review, or unsafe recovery.

Secure-isolation end state

LLM clients hold no Gitea credentials or privileged infrastructure access, and interact only through authenticated, encrypted, server-authorized, sanitized MCP operations.

Coordination-only umbrella. This issue does **not** restate or duplicate the implementation scope of #887 or #929. ## Summary Two independent programs must both complete before unattended multi-client operation is safe: #887 (transactional author workflows for multiple LLM clients) and #929 (remote MCP deployment). Neither epic references the other, and neither owns the joint end state. **Goal supported:** both — multi-LLM and secure isolation. ## Problem The two end states are coupled. Safe concurrency without credential isolation still leaves every workstation holding a Gitea token. Credential isolation without concurrency safety still serializes the fleet. Today nothing tracks the conjunction, and nothing prevents unattended scheduling from starting once only one half completes. ## Current evidence - #887's completion gate names two clients and the author role only. - #929's completion gate names two clients across author, reviewer, and merger. - Neither epic names the other. - No `roadmap`-labelled issue links them. #820 is the control-plane architecture program, and #887 explicitly classes it as different scope. #75 and #10 are closed. ## Scope - Link the canonical epics. - Own the joint completion definition. - Own the combined certification gate. - Track the cross-cutting canaries. ## Non-goals - Implementing anything. - Re-specifying the children of #887 or #929. - Changing the role taxonomy or Gitea-side branch protection. ## Dependencies - #887 — transactional author workflows safe for multiple LLM clients. - #929 — remote MCP deployment. - The concurrency canary, the credential-exfiltration canary, and the combined certification gate. Child issue numbers are linked in a follow-up roadmap summary comment on this issue. ## Definition of done Both end states below hold, both canaries pass, and the combined gate is enforced in code rather than by convention. ### Multi-LLM end state Multiple independent clients work simultaneously without identity reuse, repository crossover, lease theft, duplicate work, invalid review, or unsafe recovery. ### Secure-isolation end state LLM clients hold no Gitea credentials or privileged infrastructure access, and interact only through authenticated, encrypted, server-authorized, sanitized MCP operations.
jcwalker3 commented 2026-07-28 03:07:51 -05:00
Author
Owner
Copy Link
Copy Source

[THREAD STATE LEDGER] Issue #955 — linked epics, both canaries, the certification gate, and the combined completion state

What is true now

  • Server-side decision state: this umbrella now links both canonical epics and owns the combined certification gate. Every requirement across both goals has a canonical owner at master aad5c8b42361d380a8eeb07b94b90815e594c2c5.
  • Local verdict/state: prgs-author session, identity jcwalker3, remote prgs, repo Scaled-Tech-Consulting/Gitea-Tools. Runtime parity verified: startup_head, daemon_start_head, local_head, current_head, and live_remote_head all aad5c8b42361d380a8eeb07b94b90815e594c2c5; mutation_safe true; live_stale false; restart_required false.
  • Latest known validation: all ten issues created this session were read back natively with issue state open and valid workflow labels.

Linked canonical epics

Epic Scope Issue state
#887 Transactional author workflows safe for multiple LLM clients open
#929 Migrate the Gitea MCP fleet to a remote MCP deployment open

This umbrella does not restate or duplicate either epic's implementation scope. It owns only the conjunction.

The two canaries

Canary Goal Parent Depends on
#963 — five concurrent LLM clients with a negative concurrency suite multi-LLM #887 #948, #949, #890, #891, #896, #916
#962 — credential-exfiltration probe against the remote MCP endpoint secure isolation #929 #938, #957, #958, #959, #961

Each exists because the corresponding epic's completion gate is prose in an epic body that no code consults. #887 and #929 each name two clients; the operator runs five scheduled workers. #948 AC24 runs simulated clients inside pytest rather than five real concurrent ones. #700 records a session whose final report asserted no credential leak while its own trace showed token material, which is why #962 must be adversarial and externally run rather than self-asserted.

The combined certification gate

#964 — depends on #962, #963, and #899. It records a durable certification naming each canary, the commit certified, the timestamp, and the evidence, then makes enabling or running any unattended scheduled worker fail closed until both certifications are current for the code being run.

#899 answers "the operator turned it off." #964 answers "it was never certified on." They are different states with different lifetimes and neither substitutes for the other.

The requirement this umbrella enforces

Unattended scheduling remains fail closed until all three hold:

  1. #963 passes — five real clients complete concurrent cycles with every negative case refused.
  2. #962 passes — no probe obtains credential material, and the canary is proven capable of failing against a deliberately weakened build.
  3. #964 is current — a certification exists, is bound to the commit being run, and has not expired or been revoked.

A certification for a superseded commit, an expired certification, or only one of the two canaries is insufficient. The certification store must live where an LLM client cannot write it, which is satisfied once #961 completes.

Combined completion state

Multi-LLM: multiple independent clients work simultaneously without identity reuse, repository crossover, lease theft, duplicate work, invalid review, or unsafe recovery. Owned by #887 and its children, #948, #949, #896, #916, #792, #793, #900, and proven by #963.

Secure isolation: LLM clients hold no Gitea credentials or privileged infrastructure access, and interact only through authenticated, encrypted, server-authorized, sanitized MCP operations. Owned by #929 and its children plus #956, #957, #958, #959, #960, objectively completed by #961, and proven by #962.

Certification: unattended scheduling is impossible until both canaries certify and #964 holds a current certification.

Critical path

#887 ──> P0 children #888, #889, #890, #891 ──┐
#948, #949 ───────────────────────────────────┤──> #963 ──┐
#896, #916 ───────────────────────────────────┘           │
                                                          ├──> #964 ──> unattended scheduling permitted
#929 ──> #931 ──> #932 ──> #933/#934/#935/#937 ──> #938 ──┤
#930 ──> #956 ──> #957/#958/#959 ──> #960 ──> #961 ──> #962
#899 ─────────────────────────────────────────────────────┘

What changed

  • Server-side mutation ledger: this umbrella #955 and nine sibling issues #956 through #964 created; roadmap summary comments posted on #887 and #929; this comment. No existing issue body, label, branch, pull request, or lease was modified.
  • Local: none. No branch, worktree, commit, or push.

What is blocked

  • Blocker classification: no blocker.
  • #964 carries the blocked status label pending #962, #963, and #899, which is its designed state.

Who/what acts next

  • Next actor: author.
  • Required action: begin the two unblocked entry points — #931 and #956 on the secure-isolation side, and the #887 P0 children on the multi-LLM side.
  • Do not do: do not enable unattended scheduling before #964 holds a current certification; do not modify or recover #949; do not modify PR #954.

Canonical Issue State

STATE:
open — both epics linked; both canaries tracked; certification gate tracked as #964

WHO_IS_NEXT:
author

NEXT_ACTION:
Begin the unblocked entry points: #931 and #956 for secure isolation, and #888, #889, #890, #891 for multi-LLM.

NEXT_PROMPT:

Role: AUTHOR
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
Issue: one of #931, #956, #888, #889, #890, #891

1. gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind a branches/ worktree.
2. Implement the selected issue's acceptance criteria only; do not absorb siblings.
3. Do not enable unattended scheduling; #964 gates it and is not yet satisfied.
4. Do not modify or recover #949. Do not modify PR #954.
5. Open a PR with a Closes reference for that issue; stop; hand off to an independent reviewer.

WHAT_HAPPENED:
A live roadmap audit at master aad5c8b423 found that the two programs required for safe unattended multi-client operation were tracked independently, referenced each other nowhere, and jointly left eighteen requirements without a canonical owner. This umbrella and nine sibling issues were created to close that gap: #956 through #962 for secure isolation, #963 for multi-LLM concurrency proof, and #964 for the combined certification gate. Roadmap summary comments were posted on #887 and #929.

WHY:
Safe concurrency without credential isolation still leaves every workstation holding a Gitea token, and credential isolation without concurrency safety still serializes the fleet. Neither epic owned the conjunction, and nothing prevented unattended scheduling from starting once only one half completed. #964 makes that impossible by requiring both canaries to certify against the exact commit being run.

ISSUE: 955

RELATED_PRS:
954 (PR state closed, merge_commit_sha aad5c8b42361d380a8eeb07b94b90815e594c2c5; satisfies #953)

BLOCKERS:
none

VALIDATION:
Parity verified before and after every mutation and unchanged at aad5c8b423 with mutation_safe true, live_stale false, restart_required false. The create_issue capability was resolved immediately before each of the ten creations, and comment_issue immediately before each of the three comments. Every created issue was read back natively with issue state open, correct title, complete body, and valid workflow labels carrying exactly one type label and one status label. A duplicate search after the final creation returned exactly one instance of each of the ten new titles.

LAST_UPDATED_BY:
jcwalker3 / prgs-author / AUTHOR / 2026-07-28

[THREAD STATE LEDGER] Issue #955 — linked epics, both canaries, the certification gate, and the combined completion state **What is true now** - Server-side decision state: this umbrella now links both canonical epics and owns the combined certification gate. Every requirement across both goals has a canonical owner at master `aad5c8b42361d380a8eeb07b94b90815e594c2c5`. - Local verdict/state: prgs-author session, identity jcwalker3, remote prgs, repo Scaled-Tech-Consulting/Gitea-Tools. Runtime parity verified: startup_head, daemon_start_head, local_head, current_head, and live_remote_head all `aad5c8b42361d380a8eeb07b94b90815e594c2c5`; mutation_safe true; live_stale false; restart_required false. - Latest known validation: all ten issues created this session were read back natively with issue state open and valid workflow labels. **Linked canonical epics** | Epic | Scope | Issue state | | --- | --- | --- | | #887 | Transactional author workflows safe for multiple LLM clients | open | | #929 | Migrate the Gitea MCP fleet to a remote MCP deployment | open | This umbrella does not restate or duplicate either epic's implementation scope. It owns only the conjunction. **The two canaries** | Canary | Goal | Parent | Depends on | | --- | --- | --- | --- | | #963 — five concurrent LLM clients with a negative concurrency suite | multi-LLM | #887 | #948, #949, #890, #891, #896, #916 | | #962 — credential-exfiltration probe against the remote MCP endpoint | secure isolation | #929 | #938, #957, #958, #959, #961 | Each exists because the corresponding epic's completion gate is prose in an epic body that no code consults. #887 and #929 each name two clients; the operator runs five scheduled workers. #948 AC24 runs simulated clients inside pytest rather than five real concurrent ones. #700 records a session whose final report asserted no credential leak while its own trace showed token material, which is why #962 must be adversarial and externally run rather than self-asserted. **The combined certification gate** **#964** — depends on #962, #963, and #899. It records a durable certification naming each canary, the commit certified, the timestamp, and the evidence, then makes enabling or running any unattended scheduled worker fail closed until both certifications are current for the code being run. #899 answers "the operator turned it off." #964 answers "it was never certified on." They are different states with different lifetimes and neither substitutes for the other. **The requirement this umbrella enforces** Unattended scheduling remains fail closed until **all three** hold: 1. #963 passes — five real clients complete concurrent cycles with every negative case refused. 2. #962 passes — no probe obtains credential material, and the canary is proven capable of failing against a deliberately weakened build. 3. #964 is current — a certification exists, is bound to the commit being run, and has not expired or been revoked. A certification for a superseded commit, an expired certification, or only one of the two canaries is insufficient. The certification store must live where an LLM client cannot write it, which is satisfied once #961 completes. **Combined completion state** Multi-LLM: multiple independent clients work simultaneously without identity reuse, repository crossover, lease theft, duplicate work, invalid review, or unsafe recovery. Owned by #887 and its children, #948, #949, #896, #916, #792, #793, #900, and proven by #963. Secure isolation: LLM clients hold no Gitea credentials or privileged infrastructure access, and interact only through authenticated, encrypted, server-authorized, sanitized MCP operations. Owned by #929 and its children plus #956, #957, #958, #959, #960, objectively completed by **#961**, and proven by #962. Certification: unattended scheduling is impossible until both canaries certify and #964 holds a current certification. **Critical path** ``` #887 ──> P0 children #888, #889, #890, #891 ──┐ #948, #949 ───────────────────────────────────┤──> #963 ──┐ #896, #916 ───────────────────────────────────┘ │ ├──> #964 ──> unattended scheduling permitted #929 ──> #931 ──> #932 ──> #933/#934/#935/#937 ──> #938 ──┤ #930 ──> #956 ──> #957/#958/#959 ──> #960 ──> #961 ──> #962 #899 ─────────────────────────────────────────────────────┘ ``` **What changed** - Server-side mutation ledger: this umbrella #955 and nine sibling issues #956 through #964 created; roadmap summary comments posted on #887 and #929; this comment. No existing issue body, label, branch, pull request, or lease was modified. - Local: none. No branch, worktree, commit, or push. **What is blocked** - Blocker classification: no blocker. - #964 carries the blocked status label pending #962, #963, and #899, which is its designed state. **Who/what acts next** - Next actor: author. - Required action: begin the two unblocked entry points — #931 and #956 on the secure-isolation side, and the #887 P0 children on the multi-LLM side. - Do not do: do not enable unattended scheduling before #964 holds a current certification; do not modify or recover #949; do not modify PR #954. ## Canonical Issue State STATE: open — both epics linked; both canaries tracked; certification gate tracked as #964 WHO_IS_NEXT: author NEXT_ACTION: Begin the unblocked entry points: #931 and #956 for secure isolation, and #888, #889, #890, #891 for multi-LLM. NEXT_PROMPT: ```text Role: AUTHOR Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Issue: one of #931, #956, #888, #889, #890, #891 1. gitea_whoami + gitea_resolve_task_capability(work_issue) on prgs-author; bind a branches/ worktree. 2. Implement the selected issue's acceptance criteria only; do not absorb siblings. 3. Do not enable unattended scheduling; #964 gates it and is not yet satisfied. 4. Do not modify or recover #949. Do not modify PR #954. 5. Open a PR with a Closes reference for that issue; stop; hand off to an independent reviewer. ``` WHAT_HAPPENED: A live roadmap audit at master aad5c8b42361d380a8eeb07b94b90815e594c2c5 found that the two programs required for safe unattended multi-client operation were tracked independently, referenced each other nowhere, and jointly left eighteen requirements without a canonical owner. This umbrella and nine sibling issues were created to close that gap: #956 through #962 for secure isolation, #963 for multi-LLM concurrency proof, and #964 for the combined certification gate. Roadmap summary comments were posted on #887 and #929. WHY: Safe concurrency without credential isolation still leaves every workstation holding a Gitea token, and credential isolation without concurrency safety still serializes the fleet. Neither epic owned the conjunction, and nothing prevented unattended scheduling from starting once only one half completed. #964 makes that impossible by requiring both canaries to certify against the exact commit being run. ISSUE: 955 RELATED_PRS: 954 (PR state closed, merge_commit_sha aad5c8b42361d380a8eeb07b94b90815e594c2c5; satisfies #953) BLOCKERS: none VALIDATION: Parity verified before and after every mutation and unchanged at aad5c8b42361d380a8eeb07b94b90815e594c2c5 with mutation_safe true, live_stale false, restart_required false. The create_issue capability was resolved immediately before each of the ten creations, and comment_issue immediately before each of the three comments. Every created issue was read back natively with issue state open, correct title, complete body, and valid workflow labels carrying exactly one type label and one status label. A duplicate search after the final creation returned exactly one instance of each of the ten new titles. LAST_UPDATED_BY: jcwalker3 / prgs-author / AUTHOR / 2026-07-28
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels architecture concurrency control-plane roadmap security status:ready tracker type:feature workflow-hardening
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#955