mathias/gitea-mcp
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

create_project_from_template partial_failure cites hyperguild new-project, which is unverified #46

New Issue
Closed
opened 2026-07-03 21:40:00 +00:00 by mathias · 1 comment
mathias commented 2026-07-03 21:40:00 +00:00
Owner
Copy Link
Copy Source

Problem

When the infra#179 async-generate race blocks API-side substitution, create_project_from_template returns a partial_failure that says:

repo created, but its branch (…) was not writable within Ns … Finalize locally with hyperguild new-project (clone + substitute, no API race).

That message asserts hyperguild new-project as a working finalize path — but hyperguild new-project is not currently verified to work. We're handing the caller a fallback we haven't confirmed, which is worse than no suggestion (they burn time on a broken path).

Fix options

  1. Verify hyperguild new-project end-to-end and, if it works, keep the message (ideally pin the exact invocation). Best outcome.
  2. Soften the wording until it's verified — e.g. "substitution is incomplete (N file(s) done); finish the placeholder substitution manually (clone the repo and replace __PROJECT_NAME__ / __MODULE_PATH__), or retry once the branch is writable." Don't name a tool we can't vouch for.

Where

internal/tools/create_project_from_template.go — the strings.Contains(result.PartialFailure, "branch does not exist") remap block that builds the infra#179 message.

Refs

  • Surfaced 2026-07-03 while fixing #44 (default-template parameterization). The template fix is verified; this is about the fallback guidance the tool prints when the infra#179 race still bites.
## Problem When the infra#179 async-generate race blocks API-side substitution, `create_project_from_template` returns a `partial_failure` that says: > repo created, but its branch (…) was not writable within Ns … Finalize locally with `hyperguild new-project` (clone + substitute, no API race). That message asserts `hyperguild new-project` as a working finalize path — but **`hyperguild new-project` is not currently verified to work**. We're handing the caller a fallback we haven't confirmed, which is worse than no suggestion (they burn time on a broken path). ## Fix options 1. **Verify `hyperguild new-project` end-to-end** and, if it works, keep the message (ideally pin the exact invocation). Best outcome. 2. **Soften the wording** until it's verified — e.g. "substitution is incomplete (N file(s) done); finish the placeholder substitution manually (clone the repo and replace `__PROJECT_NAME__` / `__MODULE_PATH__`), or retry once the branch is writable." Don't name a tool we can't vouch for. ## Where `internal/tools/create_project_from_template.go` — the `strings.Contains(result.PartialFailure, "branch does not exist")` remap block that builds the infra#179 message. ## Refs - Surfaced 2026-07-03 while fixing #44 (default-template parameterization). The template fix is verified; this is about the fallback guidance the tool prints when the infra#179 race still bites.
mathias commented 2026-07-03 21:46:14 +00:00
Author
Owner
Copy Link
Copy Source

Dug into it. hyperguild new-project does not exist — the hyperguild CLI (cmd/hyperguild/main.go) registers only tier, brain, mode. It was specced (2026-05-03-spec-hyperguild-cli) but never built (or dropped in the #75/#76 single-harness consolidation). The message was pointing callers at a dead command.

Fixed in v0.5.1: extracted the infra#179 guidance into a pure infra179FinalizeMessage() and reworded it (and the tool descriptor) to name the actual remaining work — clone the repo and substitute the leftover __PROJECT_NAME__ / __MODULE_PATH__ placeholders, or retry — with no reference to any scaffolding CLI. Unit-tested (TestInfra179FinalizeMessage asserts the wording and that hyperguild new-project is absent). task check green; deploying via CD.

Adjacent finding (separate, filing/handling apart): the real local scaffolder is task new-project → ~/dev/scripts/new-project.sh, but it has a stale-host bug (http://gitea.d-ma.be/... download + gitea.d-ma.be baked into the module path) that breaks it post-rename. It's also a from-scratch local scaffold, not a finalize-existing-repo step, so it was never the right fallback here anyway. Not a gitea-mcp issue — tracked in memory; fixing it is a local-dev tooling task.

Closing #46.

Dug into it. **`hyperguild new-project` does not exist** — the hyperguild CLI (`cmd/hyperguild/main.go`) registers only `tier`, `brain`, `mode`. It was specced (`2026-05-03-spec-hyperguild-cli`) but never built (or dropped in the #75/#76 single-harness consolidation). The message was pointing callers at a dead command. Fixed in v0.5.1: extracted the infra#179 guidance into a pure `infra179FinalizeMessage()` and reworded it (and the tool descriptor) to name the actual remaining work — clone the repo and substitute the leftover `__PROJECT_NAME__` / `__MODULE_PATH__` placeholders, or retry — with no reference to any scaffolding CLI. Unit-tested (`TestInfra179FinalizeMessage` asserts the wording and that `hyperguild new-project` is absent). `task check` green; deploying via CD. **Adjacent finding (separate, filing/handling apart):** the *real* local scaffolder is `task new-project` → `~/dev/scripts/new-project.sh`, but it has a stale-host bug (`http://gitea.d-ma.be/...` download + `gitea.d-ma.be` baked into the module path) that breaks it post-rename. It's also a from-scratch local scaffold, not a finalize-existing-repo step, so it was never the right fallback here anyway. Not a gitea-mcp issue — tracked in memory; fixing it is a local-dev tooling task. Closing #46.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
mathias
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/gitea-mcp#46