Keep structured issue templates GitHub-only #824

New issue

Closed

opened 2026-07-09 17:40:23 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 17:40:23 +00:00

Member

Goal

Remove the structured issue-template/form behavior from the Forgejo side. Structured issue forms are only needed for the GitHub front door.

Context

Kai clarified that the structured issue template stuff should not exist on the Forgejo side. The GitHub mirror/front-door can keep .github/ISSUE_TEMPLATE/*.yml, but Forgejo is canonical for ward operations and should not get structured issue form/template machinery from ward.

A quick read of the current checkout shows issue-form YAML under .github/ISSUE_TEMPLATE/ and no obvious .forgejo/ISSUE_TEMPLATE/ directory. The implementation should still inspect the full code/docs/release path for any Forgejo-side install, sync, generation, or documentation that treats those structured templates as a Forgejo feature.

Scope

Keep GitHub issue forms/templates intact.
Remove any Forgejo-side issue template or structured issue form files if they exist in generated assets, release packaging, examples, docs, or install/sync paths.
Remove or update docs that imply Forgejo should use the structured issue forms.
Ensure release/package/mirror logic does not copy .github/ISSUE_TEMPLATE into Forgejo-facing locations or advertise it as canonical Forgejo behavior.
Preserve ordinary Forgejo issue creation, issue comments, reservations, and ward outcome comments.
Preserve any GitHub-side issue template config and docs that are explicitly about the GitHub front door.

Acceptance

Structured issue forms remain available only under the GitHub-side template surface.
No .forgejo or Forgejo-facing generated/release path installs or advertises structured issue templates.
Docs clearly distinguish GitHub issue forms from Forgejo canonical issue operations.
Tests or a focused grep/regression check cover the removed Forgejo-side path if code exists for it.
Repo validation passes through ward.

## Goal Remove the structured issue-template/form behavior from the Forgejo side. Structured issue forms are only needed for the GitHub front door. ## Context Kai clarified that the structured issue template stuff should not exist on the Forgejo side. The GitHub mirror/front-door can keep `.github/ISSUE_TEMPLATE/*.yml`, but Forgejo is canonical for ward operations and should not get structured issue form/template machinery from ward. A quick read of the current checkout shows issue-form YAML under `.github/ISSUE_TEMPLATE/` and no obvious `.forgejo/ISSUE_TEMPLATE/` directory. The implementation should still inspect the full code/docs/release path for any Forgejo-side install, sync, generation, or documentation that treats those structured templates as a Forgejo feature. ## Scope * Keep GitHub issue forms/templates intact. * Remove any Forgejo-side issue template or structured issue form files if they exist in generated assets, release packaging, examples, docs, or install/sync paths. * Remove or update docs that imply Forgejo should use the structured issue forms. * Ensure release/package/mirror logic does not copy `.github/ISSUE_TEMPLATE` into Forgejo-facing locations or advertise it as canonical Forgejo behavior. * Preserve ordinary Forgejo issue creation, issue comments, reservations, and ward outcome comments. * Preserve any GitHub-side issue template config and docs that are explicitly about the GitHub front door. ## Acceptance * Structured issue forms remain available only under the GitHub-side template surface. * No `.forgejo` or Forgejo-facing generated/release path installs or advertises structured issue templates. * Docs clearly distinguish GitHub issue forms from Forgejo canonical issue operations. * Tests or a focused grep/regression check cover the removed Forgejo-side path if code exists for it. * Repo validation passes through ward.

coilyco-ops commented

2026-07-09 17:40:34 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-824 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T17:40:32Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#824 · branch issue-824 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-824 · ward v0.493.0 · dispatched 2026-07-09T17:40:32Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-824` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T17:40:32Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#824` · branch `issue-824` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-824` · ward `v0.493.0` · dispatched `2026-07-09T17:40:32Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 17:47:17 +00:00

docs: keep issue forms GitHub-only

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 17:48:02 +00:00

Keep structured issue templates GitHub-only #829

coilyco-ops closed this issue

2026-07-09 17:49:07 +00:00

coilyco-ops commented

2026-07-09 17:49:52 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: skipped because review gate skipped by --skip-review / --no-review-gate
felt: straightforward
confidence: high
surprises: Forgejo PR create is API-only here, so I used the REST path.
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped because review gate skipped by --skip-review / --no-review-gate felt: straightforward confidence: high surprises: Forgejo PR create is API-only here, so I used the REST path. follow-ups: none </details>