Skip to content

chore: fill derivable placeholders, drop false ARCHITECTURE, surface the rest - #58

Open
hyperpolymath wants to merge 3 commits into
mainfrom
chore/estate-topup
Open

chore: fill derivable placeholders, drop false ARCHITECTURE, surface the rest#58
hyperpolymath wants to merge 3 commits into
mainfrom
chore/estate-topup

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Automated estate top-up. Nothing here invents a value.

Filled — every token with one mechanical answer (owner, repo, forge, author, dates, project name, main branch). Identity from the git remote, dates from the clock, name from the README H1.

Not filled, on purposeSECURITY_EMAIL (two competing addresses exist in the estate), RESPONSE_TIME, CONDUCT_TEAM (substitutes into "a {{CONDUCT_TEAM}} member", which is not English), WEBSITE, PROJECT_DESCRIPTION, LANG_STACK. More than one defensible answer exists, and a confident wrong value is worse than a visible gap.

DeletedARCHITECTURE.md where it is byte-identical to the 346-copy estate boilerplate (blob 607e3d8c). Those 33 lines describe a src/ tests/ docs/ scripts/ config/ tree this repo does not have. Matched by hash, so a genuinely written ARCHITECTURE can never be caught by it.

CODEOWNERS — the solo form from standards/CODEOWNERS-POLICY.adoc Rule 1, which forbids a catch-all where the only owner is the sole maintainer. templates/CODEOWNERS contradicts that policy; the policy is versioned, dated and resolves standards#55, so it wins. Genuine co-owners (Rule 2) are untouched.

SurfacedREQUIRES_INITIALISATION.md plus a priority action in 0-AI-MANIFEST.a2ml, listing every remaining token, what it means, which files it belongs in, why it was not done already, and that it is to be deleted only when the work is genuinely complete.

Built from a fresh clone of origin/main, never a local checkout — several of those are dirty and hold unpushed commits.

🤖 Generated with Claude Code

…the rest

Estate top-up pass. Three separate things, none of which invents a value.

FILLED — every token with a single mechanical answer: OWNER, REPO, FORGE,
PROJECT, PACKAGE_NAME, PROJECT_NAME, AUTHOR, AUTHOR_EMAIL, CONDUCT_EMAIL,
AUTHOR_FIRST/LAST/INITIALS, CURRENT_YEAR, CURRENT_DATE, DATE, MAIN_BRANCH.
Identity comes from the git remote, dates from the clock, project name from the
README H1 where there is one.

Deliberately NOT filled, because more than one defensible answer exists and a
confident wrong value is worse than a visible gap: SECURITY_EMAIL (two competing
addresses are in use across the estate), RESPONSE_TIME, CONDUCT_TEAM (which
substitutes into "a {{CONDUCT_TEAM}} member", not English), WEBSITE,
PROJECT_DESCRIPTION, LANG_STACK.

DELETED — ARCHITECTURE.md, where it is byte-identical to the 346-copy estate
boilerplate (blob 607e3d8c). Those 33 lines describe a src/ tests/ docs/
scripts/ config/ tree that this repo does not have, so the file is not merely
uninformative, it is wrong. Genuinely written ARCHITECTURE files are matched by
hash and left alone. No file beats a confidently false one.

CODEOWNERS — rewritten to the solo form mandated by
hyperpolymath/standards CODEOWNERS-POLICY.adoc Rule 1, which forbids a catch-all
line where the only owner is the sole maintainer. The estate's own
templates/CODEOWNERS contradicts that policy; the policy is versioned, dated and
resolves standards#55, so it wins. Files naming a genuine co-owner are Rule 2
and are untouched. Note @hyperpolymath and @metadatastician are the same person,
so a file naming the other account is a copy artifact that silently routed
review requests to the wrong account.

SURFACED — REQUIRES_INITIALISATION.md, and a priority action in
0-AI-MANIFEST.a2ml. Tokens that need a decision no script can make are left
visibly unfilled rather than faked or quietly deleted. The marker says what each
one is, which files it belongs in, why it was not done already, and that it must
be deleted only once the work is genuinely finished.
@gitar-bot

gitar-bot Bot commented Aug 5, 2026

Copy link
Copy Markdown

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review ⚠️ Changes requested 0 resolved / 4 findings

Fills derivable metadata placeholders across the estate but inserts the display name 'What Is Alloyiser?' into URL positions, Guix package definitions, dev container paths, and BibTeX citation keys, producing broken links and invalid syntax.

⚠️ Bug: Display name substituted into repo URLs, producing broken links

📄 .guix-channel:10 📄 .guix-channel:17 📄 guix.scm:66 📄 docs/attribution/CITATIONS.adoc:12 📄 docs/attribution/CITATIONS.adoc:19 📄 docs/attribution/CITATIONS.adoc:23 📄 docs/attribution/CITATIONS.adoc:27 📄 docs/attribution/CITATIONS.adoc:31

{{PROJECT_NAME}} was filled with the display string "What Is Alloyiser?" even in URL positions that expected the repo slug. This yields invalid URLs like https://github.com/hyperpolymath/What Is Alloyiser? (spaces + ?), which do not resolve to the actual repo hyperpolymath/alloyiser. Replace the project name with the repo slug alloyiser in these URLs (the OWNER/REPO templates elsewhere in this same PR were correctly filled to hyperpolymath/alloyiser).

Use the repo slug, not the display name, in .guix-channel and guix.scm home-page; apply the same alloyiser slug to the GitHub URLs in CITATIONS.adoc.
(url "https://github.com/hyperpolymath/alloyiser")
⚠️ Bug: Guix channel/package names contain spaces and '?', breaking Guix

📄 .guix-channel:9 📄 guix.scm:21

Guix channel names are read as Scheme symbols and package name fields must be lowercase identifiers without spaces. (name 'What Is Alloyiser?) in .guix-channel and (name "What Is Alloyiser?") in guix.scm will fail to parse/build (guix pull, guix build -f guix.scm). The display name is not a valid identifier here. Use a slug such as alloyiser.

Use the lowercase repo slug as the Guix identifier.
;; .guix-channel
(name 'alloyiser)

;; guix.scm
(name "alloyiser")
⚠️ Bug: Dev container WORKDIR path has unquoted spaces and glob char

📄 .devcontainer/Containerfile:6 📄 .devcontainer/Containerfile:27

WORKDIR /workspaces/What Is Alloyiser? sets a workspace path containing spaces and a ? glob character. This produces a surprising/broken workspace path and can break tooling and shell operations that assume the devcontainer workspace folder. Use a slug-safe directory name (e.g. /workspaces/alloyiser) and update the podman build -t What Is Alloyiser?-dev example on line 6 which is also an invalid image tag.

Use the slug for the workspace path and image tag.
# Build: podman build -t alloyiser-dev -f .devcontainer/Containerfile .
...
WORKDIR /workspaces/alloyiser
💡 Bug: BibTeX cite key contains spaces and '?', invalid entry

📄 docs/attribution/CITATIONS.adoc:8

@software{What Is Alloyiser?_2026, is not a valid BibTeX citation key — keys cannot contain spaces or ?, so any consumer parsing this .bib snippet will fail or truncate the key. Use a slug-based key such as alloyiser_2026 (the human title is already carried by the title field).

Use a slug for the cite key; keep the display name only in the title field.
@software{alloyiser_2026,
  author = {Jewell, Jonathan},
  title = {What Is Alloyiser?},
🤖 Prompt for agents
Code Review: Fills derivable metadata placeholders across the estate but inserts the display name 'What Is Alloyiser?' into URL positions, Guix package definitions, dev container paths, and BibTeX citation keys, producing broken links and invalid syntax.

1. ⚠️ Bug: Display name substituted into repo URLs, producing broken links
   Files: .guix-channel:10, .guix-channel:17, guix.scm:66, docs/attribution/CITATIONS.adoc:12, docs/attribution/CITATIONS.adoc:19, docs/attribution/CITATIONS.adoc:23, docs/attribution/CITATIONS.adoc:27, docs/attribution/CITATIONS.adoc:31

   `{{PROJECT_NAME}}` was filled with the display string "What Is Alloyiser?" even in URL positions that expected the repo slug. This yields invalid URLs like `https://github.com/hyperpolymath/What Is Alloyiser?` (spaces + `?`), which do not resolve to the actual repo `hyperpolymath/alloyiser`. Replace the project name with the repo slug `alloyiser` in these URLs (the OWNER/REPO templates elsewhere in this same PR were correctly filled to `hyperpolymath/alloyiser`).

   Fix (Use the repo slug, not the display name, in .guix-channel and guix.scm home-page; apply the same alloyiser slug to the GitHub URLs in CITATIONS.adoc.):
   (url "https://github.com/hyperpolymath/alloyiser")

2. ⚠️ Bug: Guix channel/package names contain spaces and '?', breaking Guix
   Files: .guix-channel:9, guix.scm:21

   Guix channel names are read as Scheme symbols and package `name` fields must be lowercase identifiers without spaces. `(name 'What Is Alloyiser?)` in .guix-channel and `(name "What Is Alloyiser?")` in guix.scm will fail to parse/build (`guix pull`, `guix build -f guix.scm`). The display name is not a valid identifier here. Use a slug such as `alloyiser`.

   Fix (Use the lowercase repo slug as the Guix identifier.):
   ;; .guix-channel
   (name 'alloyiser)
   
   ;; guix.scm
   (name "alloyiser")

3. ⚠️ Bug: Dev container WORKDIR path has unquoted spaces and glob char
   Files: .devcontainer/Containerfile:6, .devcontainer/Containerfile:27

   `WORKDIR /workspaces/What Is Alloyiser?` sets a workspace path containing spaces and a `?` glob character. This produces a surprising/broken workspace path and can break tooling and shell operations that assume the devcontainer workspace folder. Use a slug-safe directory name (e.g. `/workspaces/alloyiser`) and update the `podman build -t What Is Alloyiser?-dev` example on line 6 which is also an invalid image tag.

   Fix (Use the slug for the workspace path and image tag.):
   # Build: podman build -t alloyiser-dev -f .devcontainer/Containerfile .
   ...
   WORKDIR /workspaces/alloyiser

4. 💡 Bug: BibTeX cite key contains spaces and '?', invalid entry
   Files: docs/attribution/CITATIONS.adoc:8

   `@software{What Is Alloyiser?_2026,` is not a valid BibTeX citation key — keys cannot contain spaces or `?`, so any consumer parsing this .bib snippet will fail or truncate the key. Use a slug-based key such as `alloyiser_2026` (the human title is already carried by the `title` field).

   Fix (Use a slug for the cite key; keep the display name only in the title field.):
   @software{alloyiser_2026,
     author = {Jewell, Jonathan},
     title = {What Is Alloyiser?},

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact
gitar display:verbose         

Important

Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

Was this helpful? React with 👍 / 👎 | Gitar

Comment thread .guix-channel
;; (name '{{PROJECT_NAME}})
;; (url "https://github.com/{{OWNER}}/{{PROJECT_NAME}}")
;; (name 'What Is Alloyiser?)
;; (url "https://github.com/hyperpolymath/What Is Alloyiser?")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Bug: Display name substituted into repo URLs, producing broken links

{{PROJECT_NAME}} was filled with the display string "What Is Alloyiser?" even in URL positions that expected the repo slug. This yields invalid URLs like https://github.com/hyperpolymath/What Is Alloyiser? (spaces + ?), which do not resolve to the actual repo hyperpolymath/alloyiser. Replace the project name with the repo slug alloyiser in these URLs (the OWNER/REPO templates elsewhere in this same PR were correctly filled to hyperpolymath/alloyiser).

Use the repo slug, not the display name, in .guix-channel and guix.scm home-page; apply the same alloyiser slug to the GitHub URLs in CITATIONS.adoc.:

(url "https://github.com/hyperpolymath/alloyiser")
  • Apply fix

Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎

Comment thread .guix-channel
;; (channel
;; (name '{{PROJECT_NAME}})
;; (url "https://github.com/{{OWNER}}/{{PROJECT_NAME}}")
;; (name 'What Is Alloyiser?)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Bug: Guix channel/package names contain spaces and '?', breaking Guix

Guix channel names are read as Scheme symbols and package name fields must be lowercase identifiers without spaces. (name 'What Is Alloyiser?) in .guix-channel and (name "What Is Alloyiser?") in guix.scm will fail to parse/build (guix pull, guix build -f guix.scm). The display name is not a valid identifier here. Use a slug such as alloyiser.

Use the lowercase repo slug as the Guix identifier.:

;; .guix-channel
(name 'alloyiser)

;; guix.scm
(name "alloyiser")
  • Apply fix

Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎

# Dev Container image for What Is Alloyiser?
# Base: Chainguard Wolfi (minimal, supply-chain-secure)
# Build: podman build -t {{PROJECT_NAME}}-dev -f .devcontainer/Containerfile .
# Build: podman build -t What Is Alloyiser?-dev -f .devcontainer/Containerfile .

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Bug: Dev container WORKDIR path has unquoted spaces and glob char

WORKDIR /workspaces/What Is Alloyiser? sets a workspace path containing spaces and a ? glob character. This produces a surprising/broken workspace path and can break tooling and shell operations that assume the devcontainer workspace folder. Use a slug-safe directory name (e.g. /workspaces/alloyiser) and update the podman build -t What Is Alloyiser?-dev example on line 6 which is also an invalid image tag.

Use the slug for the workspace path and image tag.:

# Build: podman build -t alloyiser-dev -f .devcontainer/Containerfile .
...
WORKDIR /workspaces/alloyiser
  • Apply fix

Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎

@software{{{PROJECT_NAME}}_2026,
author = {{{AUTHOR_LAST}}, {{AUTHOR_FIRST}}},
title = {{{PROJECT_NAME}}},
@software{What Is Alloyiser?_2026,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Bug: BibTeX cite key contains spaces and '?', invalid entry

@software{What Is Alloyiser?_2026, is not a valid BibTeX citation key — keys cannot contain spaces or ?, so any consumer parsing this .bib snippet will fail or truncate the key. Use a slug-based key such as alloyiser_2026 (the human title is already carried by the title field).

Use a slug for the cite key; keep the display name only in the title field.:

@software{alloyiser_2026,
  author = {Jewell, Jonathan},
  title = {What Is Alloyiser?},
  • Apply fix

Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎

@gitar-bot gitar-bot Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ This PR is blocked due to unresolved code review findings.

Configure merge blocking · Maintainers can dismiss this review.

hyperpolymath and others added 2 commits August 5, 2026 14:14
…t a value

The estate top-up sweep substituted {{PROJECT}} here along with every other
token. This line is a DETECTOR list: the comment above it says these rules
detect corrupt/template/stale state files, so the tokens named in it are the
ones whose PRESENCE means a state file is broken.

Substituting it did two things. It blinded the {{PROJECT}} leak detector, and it
made the detector reject any state file containing this repo's own uppercased
name — the opposite of what the rule is for.

Same failure class as a template recipe rewriting the incident record that
documents its own bug: substituting tokens inside a thing that is ABOUT tokens.
Nothing else in this PR changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit on this branch was written by a script that read the file
through a shell command substitution. $(...) strips trailing newlines and
printf '%s' does not put one back, so the file lost its final newline and the
diff showed "\ No newline at end of file".

Content is otherwise byte-identical to that commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant