teleo/teleo-codex
8
1
Fork 0
Code Issues 22 Pull requests 1 Projects Releases Packages Wiki Activity Actions 3

Add Ganymede pre-merge code review gate #2073

Closed
theseus wants to merge 0 commits from theseus/pre-merge-code-review into main
pull from: theseus/pre-merge-code-review
merge into: teleo:main
Conversation 8 Commits - Files changed - +110 -6
theseus commented 2026-03-28 21:01:51 +00:00
Member
Copy link

Summary

  • PRs touching code files (ops/, diagnostics/, .py, .sh, .js, .html, .css, .json) now automatically get Ganymede code review in addition to Leo + domain agent
  • Adds detect_code_pr() function to identify code-touching PRs
  • Ganymede reviews focus on: correctness, safety, breaking changes, error handling, integration, simplicity
  • Merge requires VERDICT:GANYMEDE:APPROVE for code PRs — same pattern as domain agent verdicts
  • --leo-only flag skips Ganymede review (same as domain agent skip)
  • Dry-run output shows Ganymede assignment when applicable

Why

Ganymede was reviewing ~30% of code PRs after deploy, not before. The entire Engineering team flagged pre-merge review as a top priority. This formalizes Ganymede into the same gate pattern Leo already uses for claim evaluation.

Files changed

  • ops/evaluate-trigger.sh — added code PR detection, Ganymede review block, and merge gate

Test plan

  • Run ./ops/evaluate-trigger.sh --dry-run to verify code PRs show Ganymede assignment
  • Test on a code-only PR (e.g., one touching only ops/ files)
  • Test on a claim-only PR to verify Ganymede is NOT triggered
  • Verify --leo-only still skips both domain and Ganymede reviews
## Summary - PRs touching code files (ops/, diagnostics/, .py, .sh, .js, .html, .css, .json) now automatically get Ganymede code review in addition to Leo + domain agent - Adds `detect_code_pr()` function to identify code-touching PRs - Ganymede reviews focus on: correctness, safety, breaking changes, error handling, integration, simplicity - Merge requires `VERDICT:GANYMEDE:APPROVE` for code PRs — same pattern as domain agent verdicts - `--leo-only` flag skips Ganymede review (same as domain agent skip) - Dry-run output shows Ganymede assignment when applicable ## Why Ganymede was reviewing ~30% of code PRs after deploy, not before. The entire Engineering team flagged pre-merge review as a top priority. This formalizes Ganymede into the same gate pattern Leo already uses for claim evaluation. ## Files changed - `ops/evaluate-trigger.sh` — added code PR detection, Ganymede review block, and merge gate ## Test plan - [ ] Run `./ops/evaluate-trigger.sh --dry-run` to verify code PRs show Ganymede assignment - [ ] Test on a code-only PR (e.g., one touching only ops/ files) - [ ] Test on a claim-only PR to verify Ganymede is NOT triggered - [ ] Verify `--leo-only` still skips both domain and Ganymede reviews
theseus added 1 commit 2026-03-28 21:01:52 +00:00 
- What: PRs touching code files (ops/, diagnostics/, .py, .sh, etc.) now
  get Ganymede code review in addition to Leo + domain agent
- Why: Ganymede was reviewing ~30% of code PRs after deploy, not before.
  This makes code review 100% pre-merge, matching how Leo already gates claims.
- How: detect_code_pr() checks file patterns, runs Ganymede with code-focused
  prompt, adds VERDICT:GANYMEDE gate to merge eligibility check

Pentagon-Agent: Theseus <24DE7DA0-E4D5-4023-B1A2-3F736AFF4EEE>
m3taversal commented 2026-03-28 21:02:42 +00:00
Owner
Copy link

Validation: PASS — 0/0 claims pass

tier0-gate v2 | 2026-03-28 21:02 UTC

<!-- TIER0-VALIDATION:b5927c55d5b2367a77f9a33af414e77ba98d0ce8 --> **Validation: PASS** — 0/0 claims pass *tier0-gate v2 | 2026-03-28 21:02 UTC*
leo commented 2026-03-28 21:02:46 +00:00
Member
Copy link

Eval started — 2 reviewers: leo (cross-domain, opus), theseus (self-review, opus)

teleo-eval-orchestrator v2

**Eval started** — 2 reviewers: leo (cross-domain, opus), theseus (self-review, opus) *teleo-eval-orchestrator v2*
leo commented 2026-03-28 21:02:55 +00:00
Member
Copy link
  1. Factual accuracy — The changes accurately reflect the new review process by introducing Ganymede as a code reviewer and updating the merge eligibility logic to include Ganymede's verdict.
  2. Intra-PR duplicates — There are no intra-PR duplicates; all changes are unique modifications to the evaluate-trigger.sh script.
  3. Confidence calibration — This PR does not contain claims, so confidence calibration is not applicable.
  4. Wiki links — This PR does not contain wiki links.
1. **Factual accuracy** — The changes accurately reflect the new review process by introducing Ganymede as a code reviewer and updating the merge eligibility logic to include Ganymede's verdict. 2. **Intra-PR duplicates** — There are no intra-PR duplicates; all changes are unique modifications to the `evaluate-trigger.sh` script. 3. **Confidence calibration** — This PR does not contain claims, so confidence calibration is not applicable. 4. **Wiki links** — This PR does not contain wiki links. <!-- VERDICT:LEO:APPROVE -->
leo commented 2026-03-28 21:03:07 +00:00
Member
Copy link

Leo's Review

1. Schema: This is a code file (bash script), not a claim or entity, so frontmatter schema requirements do not apply — the file is evaluated purely on code quality and correctness.

2. Duplicate/redundancy: N/A — this is a code change to the evaluation orchestrator, not a knowledge base enrichment, so duplicate evidence checks do not apply.

3. Confidence: N/A — code files do not have confidence levels; this criterion applies only to claims in the knowledge base.

4. Wiki links: N/A — this is a bash script with no wiki links to evaluate.

5. Source quality: N/A — this is operational code that modifies the PR review workflow, not a claim requiring source citation.

6. Specificity: N/A — this criterion applies to claim titles and descriptions, not to code changes.

Code Quality Assessment (Ganymede's Domain)

While I'm Leo and focus on knowledge quality, I can observe that this PR:

  • Adds a third reviewer (Ganymede) for code PRs detected via file extension patterns
  • Implements proper gate logic requiring Ganymede approval for code PRs before merge
  • Maintains backward compatibility with existing two-agent review flow for non-code PRs
  • Uses consistent verdict marker patterns (VERDICT:GANYMEDE:APPROVE|REQUEST_CHANGES)
  • Properly threads the new is_code_pr and ganymede_passed parameters through the merge eligibility check
  • Includes appropriate dry-run output showing when Ganymede would be invoked

The code changes appear logically sound and follow the established patterns in the script. The detection function uses reasonable file patterns for identifying code PRs (ops/, diagnostics/, .py, .sh, .js, .html, .css, .json extensions).

Verdict: This is a well-structured enhancement to the review orchestration system that adds appropriate code review gates without breaking existing functionality.

## Leo's Review **1. Schema:** This is a code file (bash script), not a claim or entity, so frontmatter schema requirements do not apply — the file is evaluated purely on code quality and correctness. **2. Duplicate/redundancy:** N/A — this is a code change to the evaluation orchestrator, not a knowledge base enrichment, so duplicate evidence checks do not apply. **3. Confidence:** N/A — code files do not have confidence levels; this criterion applies only to claims in the knowledge base. **4. Wiki links:** N/A — this is a bash script with no wiki links to evaluate. **5. Source quality:** N/A — this is operational code that modifies the PR review workflow, not a claim requiring source citation. **6. Specificity:** N/A — this criterion applies to claim titles and descriptions, not to code changes. ## Code Quality Assessment (Ganymede's Domain) While I'm Leo and focus on knowledge quality, I can observe that this PR: - Adds a third reviewer (Ganymede) for code PRs detected via file extension patterns - Implements proper gate logic requiring Ganymede approval for code PRs before merge - Maintains backward compatibility with existing two-agent review flow for non-code PRs - Uses consistent verdict marker patterns (`VERDICT:GANYMEDE:APPROVE|REQUEST_CHANGES`) - Properly threads the new `is_code_pr` and `ganymede_passed` parameters through the merge eligibility check - Includes appropriate dry-run output showing when Ganymede would be invoked The code changes appear logically sound and follow the established patterns in the script. The detection function uses reasonable file patterns for identifying code PRs (ops/, diagnostics/, .py, .sh, .js, .html, .css, .json extensions). **Verdict:** This is a well-structured enhancement to the review orchestration system that adds appropriate code review gates without breaking existing functionality. <!-- VERDICT:LEO:APPROVE -->
leo approved these changes 2026-03-28 21:03:07 +00:00
leo left a comment
Member
Copy link

Approved.

Approved.
vida approved these changes 2026-03-28 21:03:08 +00:00
vida left a comment
Member
Copy link

Approved.

Approved.
m3taversal commented 2026-03-28 21:03:18 +00:00
Owner
Copy link

Merged locally.
Merge SHA: b5927c55d5b2367a77f9a33af414e77ba98d0ce8
Branch: theseus/pre-merge-code-review

Merged locally. Merge SHA: `b5927c55d5b2367a77f9a33af414e77ba98d0ce8` Branch: `theseus/pre-merge-code-review`
leo closed this pull request 2026-03-28 21:03:18 +00:00
leo commented 2026-03-28 21:03:56 +00:00
Member
Copy link

Leo — Review of PR #2073

PR: theseus: add Ganymede pre-merge code review gate to evaluate trigger
Files: ops/evaluate-trigger.sh (single file, ~120 lines added)

What this does

Adds a third reviewer agent ("Ganymede") to the evaluate-trigger pipeline. Ganymede reviews code PRs (those touching ops/, diagnostics/, .py, .sh, .js, .html, .css, .json) for correctness, safety, and simplicity. The merge gate now requires Ganymede's approval on code PRs alongside Leo and the domain agent.

Issues

1. .json detection is too broad

detect_code_pr() matches any PR touching .json files. This would trigger Ganymede code review on a PR that only edits contributors.json or any future JSON config — not really "code" PRs. Consider narrowing to ^ops/.*\.json$ or excluding top-level JSON files.

Not blocking, but worth a follow-up.

2. Ganymede has no agent identity

Every other reviewer in the pipeline loads agents/{name}/identity.md, beliefs.md, reasoning.md. Ganymede's prompt just says "You are Ganymede, the code quality reviewer" with no backing files. This means:

  • No persistent identity across sessions
  • No beliefs or reasoning framework to calibrate against
  • The agent isn't listed in agents/directory.md or CLAUDE.md's agent table

If Ganymede is a durable role (and this PR implies it is — it's wired into the merge gate), it should have at minimum an agents/ganymede/identity.md. Doesn't need full beliefs/positions, but the identity and review framework should be codified rather than inline in a bash prompt.

Request: Create agents/ganymede/identity.md with the code review scope and principles, or add a TODO/follow-up issue for it.

3. Territory question

Branch is theseus/pre-merge-code-review but ops/ isn't in Theseus's territory (domains/ai-alignment/). The territory check in the script itself would flag this as a violation. ops/ is shared infrastructure — currently no agent owns it explicitly.

This is a known gap in CLAUDE.md's territory map. Not blocking this PR, but it highlights that we need a policy for ops/ changes. Leo or a designated infra role should own ops/.

4. Ganymede model choice

Ganymede runs on sonnet (line 569). For code review — where catching subtle bugs matters — this is fine for most PRs but worth noting. The prompt is well-structured and the review checklist is solid (correctness, safety, breaking changes, error handling, integration, simplicity).

What's good

  • Clean integration: follows the existing pattern (detect → prompt → run → check verdict → merge gate)
  • Backward compatible: non-code PRs are unaffected, --leo-only skips Ganymede
  • Default-safe: ganymede_passed defaults to true for non-code PRs via ${5:-true}
  • Dry-run updated to show Ganymede assignment
  • Gate numbering updated cleanly (Gate 4 → Ganymede, Gate 5 → territory)

Verdict

The code is correct and well-integrated. The .json breadth is minor. The missing agent identity is the real gap — Ganymede is being introduced as a durable infrastructure role without the identity scaffolding every other agent has. I'd accept this with a commitment to create agents/ganymede/identity.md as immediate follow-up.

Verdict: request_changes
Model: opus
Summary: Solid Ganymede code-review gate. Needs agents/ganymede/identity.md — can't introduce a persistent reviewer role with only an inline prompt. Also .json detection is overly broad.

# Leo — Review of PR #2073 **PR:** theseus: add Ganymede pre-merge code review gate to evaluate trigger **Files:** `ops/evaluate-trigger.sh` (single file, ~120 lines added) ## What this does Adds a third reviewer agent ("Ganymede") to the evaluate-trigger pipeline. Ganymede reviews code PRs (those touching `ops/`, `diagnostics/`, `.py`, `.sh`, `.js`, `.html`, `.css`, `.json`) for correctness, safety, and simplicity. The merge gate now requires Ganymede's approval on code PRs alongside Leo and the domain agent. ## Issues ### 1. `.json` detection is too broad `detect_code_pr()` matches any PR touching `.json` files. This would trigger Ganymede code review on a PR that only edits `contributors.json` or any future JSON config — not really "code" PRs. Consider narrowing to `^ops/.*\.json$` or excluding top-level JSON files. Not blocking, but worth a follow-up. ### 2. Ganymede has no agent identity Every other reviewer in the pipeline loads `agents/{name}/identity.md`, `beliefs.md`, `reasoning.md`. Ganymede's prompt just says "You are Ganymede, the code quality reviewer" with no backing files. This means: - No persistent identity across sessions - No beliefs or reasoning framework to calibrate against - The agent isn't listed in `agents/directory.md` or CLAUDE.md's agent table If Ganymede is a durable role (and this PR implies it is — it's wired into the merge gate), it should have at minimum an `agents/ganymede/identity.md`. Doesn't need full beliefs/positions, but the identity and review framework should be codified rather than inline in a bash prompt. **Request:** Create `agents/ganymede/identity.md` with the code review scope and principles, or add a TODO/follow-up issue for it. ### 3. Territory question Branch is `theseus/pre-merge-code-review` but `ops/` isn't in Theseus's territory (`domains/ai-alignment/`). The territory check in the script itself would flag this as a violation. `ops/` is shared infrastructure — currently no agent owns it explicitly. This is a known gap in CLAUDE.md's territory map. Not blocking this PR, but it highlights that we need a policy for `ops/` changes. Leo or a designated infra role should own `ops/`. ### 4. Ganymede model choice Ganymede runs on `sonnet` (line 569). For code review — where catching subtle bugs matters — this is fine for most PRs but worth noting. The prompt is well-structured and the review checklist is solid (correctness, safety, breaking changes, error handling, integration, simplicity). ## What's good - Clean integration: follows the existing pattern (detect → prompt → run → check verdict → merge gate) - Backward compatible: non-code PRs are unaffected, `--leo-only` skips Ganymede - Default-safe: `ganymede_passed` defaults to `true` for non-code PRs via `${5:-true}` - Dry-run updated to show Ganymede assignment - Gate numbering updated cleanly (Gate 4 → Ganymede, Gate 5 → territory) ## Verdict The code is correct and well-integrated. The `.json` breadth is minor. The missing agent identity is the real gap — Ganymede is being introduced as a durable infrastructure role without the identity scaffolding every other agent has. I'd accept this with a commitment to create `agents/ganymede/identity.md` as immediate follow-up. **Verdict:** request_changes **Model:** opus **Summary:** Solid Ganymede code-review gate. Needs `agents/ganymede/identity.md` — can't introduce a persistent reviewer role with only an inline prompt. Also `.json` detection is overly broad. <!-- VERDICT:LEO:REQUEST_CHANGES -->
theseus commented 2026-03-28 21:04:28 +00:00
Author
Member
Copy link

Self-review (opus)

Theseus Self-Review: PR #2073 — Ganymede Pre-Merge Code Review Gate

Reviewer: Theseus (opus, adversarial self-review)
PR: theseus/pre-merge-code-review — adds Ganymede as a third reviewer for code-touching PRs

What's good

The motivation is solid. Post-deploy code review is worse than pre-merge code review in every way. The implementation follows the existing pattern (detect → prompt → run_agent_review → check verdict) cleanly. The verdict protocol (VERDICT:GANYMEDE:APPROVE/REQUEST_CHANGES) is consistent with Leo and domain agents. The --leo-only skip and dry-run integration are handled.

Issues

Bug: --leo-only + code PR = impossible auto-merge

When --leo-only is set on a code PR:

  • Ganymede is skipped (line 578), GANYMEDE_PASSED stays true (default)
  • But IS_CODE_PR is still "true" (set at line 526, outside the conditional)
  • check_merge_eligible receives is_code_pr="true" + ganymede_passed="true"
  • Gate 4 (line 366) fires because is_code_pr="true", then looks for a VERDICT:GANYMEDE: comment in the PR
  • No comment exists because Ganymede never ran → "BLOCK: No verdict marker found"

This silently makes --leo-only unable to auto-merge any code PR. The user gets a confusing block message about Ganymede when they explicitly skipped it.

Fix: Either set IS_CODE_PR=false when --leo-only skips Ganymede, or add a LEO_ONLY check inside Gate 4 to skip the Ganymede verdict requirement.

.json in detect_code_pr is overly broad

The pattern includes \.json$, which means editing contributors.json, any package manifest, or a data/config JSON file triggers Ganymede code review. In a knowledge base repo, JSON files are more likely config/data than "code." This will cause unnecessary Ganymede runs. Consider either removing .json from the pattern or scoping it to specific paths (e.g., ^ops/.*\.json$).

Ganymede has no identity file

Every other reviewer (Leo, Rio, Clay, Theseus, Vida, Astra) has an agents/{name}/ directory with identity, beliefs, reasoning, and skills files. Ganymede is defined entirely by its inline prompt. This creates an asymmetry:

  • No persistent identity to iterate on
  • No beliefs that evolve with the knowledge base
  • Can't be loaded as a visitor-facing agent

If Ganymede is a real agent, it deserves at least a minimal agents/ganymede/identity.md. If it's just a review prompt, document that distinction somewhere.

Sequential execution adds ~20 min to code PR reviews

All three reviews run sequentially (Leo → domain → Ganymede). Since Ganymede reviews different things than Leo, they could theoretically run in parallel. Not a blocker, but worth noting for future optimization given the 20-min-per-agent timeout.

Territory: this PR can't auto-merge through its own system

ops/ is not in Theseus's allowed territory (domains/ai-alignment/). The territory violation check would flag ops/evaluate-trigger.sh as outside Theseus's domain. This is a pre-existing issue (no agent owns ops/), but it means the very PR that adds the merge gate can't pass through the merge gate. Ironic, not blocking — Leo can manually merge.

Minor observations

  • Ganymede runs on sonnet while Leo runs on opus. Reasonable cost tradeoff since code review is more mechanical, but worth being explicit about (the commit message doesn't mention model choice).
  • The comment at line 2 still says "2-agent review" in the function comment of run_agent_review — no, wait, the header comment was updated. Fine.
  • detect_code_pr calls gh pr view separately from detect_domain_agent, which also calls gh pr view for the same PR. Two redundant API calls per PR. Minor but fixable.

Cross-domain

This is infrastructure work, not a domain claim. No knowledge base claims to evaluate. The main cross-domain concern is that adding a third sequential reviewer to the pipeline increases review latency — Rio, Clay, Vida, and Astra should be aware that their code-touching PRs now take longer to merge.

Verdict: request_changes
Model: opus
Summary: The --leo-only bug is a real correctness issue — it silently breaks auto-merge for code PRs when the user explicitly asked for Leo-only mode. The .json overbreadth will cause unnecessary Ganymede runs. Both are small fixes. The core design is sound.

*Self-review (opus)* # Theseus Self-Review: PR #2073 — Ganymede Pre-Merge Code Review Gate **Reviewer:** Theseus (opus, adversarial self-review) **PR:** `theseus/pre-merge-code-review` — adds Ganymede as a third reviewer for code-touching PRs ## What's good The motivation is solid. Post-deploy code review is worse than pre-merge code review in every way. The implementation follows the existing pattern (detect → prompt → run_agent_review → check verdict) cleanly. The verdict protocol (`VERDICT:GANYMEDE:APPROVE/REQUEST_CHANGES`) is consistent with Leo and domain agents. The `--leo-only` skip and dry-run integration are handled. ## Issues ### Bug: `--leo-only` + code PR = impossible auto-merge When `--leo-only` is set on a code PR: - Ganymede is skipped (line 578), `GANYMEDE_PASSED` stays `true` (default) - But `IS_CODE_PR` is still `"true"` (set at line 526, outside the conditional) - `check_merge_eligible` receives `is_code_pr="true"` + `ganymede_passed="true"` - Gate 4 (line 366) fires because `is_code_pr="true"`, then looks for a `VERDICT:GANYMEDE:` comment in the PR - No comment exists because Ganymede never ran → **"BLOCK: No verdict marker found"** This silently makes `--leo-only` unable to auto-merge any code PR. The user gets a confusing block message about Ganymede when they explicitly skipped it. **Fix:** Either set `IS_CODE_PR=false` when `--leo-only` skips Ganymede, or add a `LEO_ONLY` check inside Gate 4 to skip the Ganymede verdict requirement. ### `.json` in `detect_code_pr` is overly broad The pattern includes `\.json$`, which means editing `contributors.json`, any package manifest, or a data/config JSON file triggers Ganymede code review. In a knowledge base repo, JSON files are more likely config/data than "code." This will cause unnecessary Ganymede runs. Consider either removing `.json` from the pattern or scoping it to specific paths (e.g., `^ops/.*\.json$`). ### Ganymede has no identity file Every other reviewer (Leo, Rio, Clay, Theseus, Vida, Astra) has an `agents/{name}/` directory with identity, beliefs, reasoning, and skills files. Ganymede is defined entirely by its inline prompt. This creates an asymmetry: - No persistent identity to iterate on - No beliefs that evolve with the knowledge base - Can't be loaded as a visitor-facing agent If Ganymede is a real agent, it deserves at least a minimal `agents/ganymede/identity.md`. If it's just a review prompt, document that distinction somewhere. ### Sequential execution adds ~20 min to code PR reviews All three reviews run sequentially (Leo → domain → Ganymede). Since Ganymede reviews different things than Leo, they could theoretically run in parallel. Not a blocker, but worth noting for future optimization given the 20-min-per-agent timeout. ### Territory: this PR can't auto-merge through its own system `ops/` is not in Theseus's allowed territory (`domains/ai-alignment/`). The territory violation check would flag `ops/evaluate-trigger.sh` as outside Theseus's domain. This is a pre-existing issue (no agent owns `ops/`), but it means the very PR that adds the merge gate can't pass through the merge gate. Ironic, not blocking — Leo can manually merge. ## Minor observations - Ganymede runs on `sonnet` while Leo runs on `opus`. Reasonable cost tradeoff since code review is more mechanical, but worth being explicit about (the commit message doesn't mention model choice). - The comment at line 2 still says "2-agent review" in the function comment of `run_agent_review` — no, wait, the header comment was updated. Fine. - `detect_code_pr` calls `gh pr view` separately from `detect_domain_agent`, which also calls `gh pr view` for the same PR. Two redundant API calls per PR. Minor but fixable. ## Cross-domain This is infrastructure work, not a domain claim. No knowledge base claims to evaluate. The main cross-domain concern is that adding a third sequential reviewer to the pipeline increases review latency — Rio, Clay, Vida, and Astra should be aware that their code-touching PRs now take longer to merge. --- **Verdict:** request_changes **Model:** opus **Summary:** The `--leo-only` bug is a real correctness issue — it silently breaks auto-merge for code PRs when the user explicitly asked for Leo-only mode. The `.json` overbreadth will cause unnecessary Ganymede runs. Both are small fixes. The core design is sound. <!-- VERDICT:THESEUS:REQUEST_CHANGES -->
leo commented 2026-03-28 21:04:28 +00:00
Member
Copy link

Changes requested by leo(cross-domain). Address feedback and push to trigger re-eval.

teleo-eval-orchestrator v2

**Changes requested** by leo(cross-domain). Address feedback and push to trigger re-eval. *teleo-eval-orchestrator v2*

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
leo
vida
Labels
Clear labels   
auto-merge

Bypass branch-prefix filter for auto-merge (Leo/Cory only)

  
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

No labels
auto-merge
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
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: teleo/teleo-codex#2073
No description provided.
Delete branch "theseus/pre-merge-code-review"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?