Ein Blog

GitHub hat jetzt Agentic Workflows. Das sind Markdown-Files mit einer Yaml-Frontmatter, die Tasks definieren, dei automatisch von irgendeinem LLM getätigt werden sollen. Sie betonen sehr die “Guardrail”-Features. Definieren tut man Permissions in der Frontmatter, die ähnlich zu den normalen Workflows aussehen.

Hier deren Beispiel-Workflow für etwas, was täglich einen Status-Report macht:

---
on:
  schedule: daily
permissions:
  contents: read
  issues: read
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[team-status] "
    labels: [report, daily-status]
    close-older-issues: true
---

## Daily Issues Report

Create an upbeat daily status report for the team as a GitHub issue.

## What to include

- Recent repository activity (issues, PRs, discussions, releases, code changes)
- Progress tracking, goal reminders and highlights
- Project status and recommendations
- Actionable next steps for maintainers

Wenn ich den ono-Block so sehe, geht das dann wahrscheinlich auch bei allen üblichen Event-Triggern, die GH Actions so können. Könnte man also wahrscheinlich auch als Basistechnologie für automatisierte Code-Reviews nehmen (falls wman von denen im aktuellen Zustand etwas hält).

Mitchell Hashimoto (der hinter Ghostty, hcl, Terraform) hat ja viele Probleme mit AI-Slop-PRs. Dafür hat er jetzt einen Lösungsversuch skizziert: vouch.

Im Pinrzip ist es eine Liste von “trusted” Contributors (“trusted” wie in “macht keinen AI-Slop”, nicht in “ist kein Actor mit schlechten Intentionen”).

Die Grundidee ist, dass man im Repo eine .github/VOUCHED.td (td für “Trustdown”) hat. Die sieht bei dem Repo selbst, aber hier auch als Beispiel:

# The list of vouched (or actively denounced) users for this repository.
#
# The high-level idea is that only vouched users can participate in
# contributing to this project. And a denounced user is explicitly
# blocked from contributing (issues, PRs, etc. auto-closed). 
#
# We choose to maintain a denouncement list rather than or in addition to 
# using the platform's block features so other projects can slurp in our 
# list of denounced users if they trust us and want to adopt our prior
# knowledge about bad actors.
#
# Syntax:
#  - One handle per line (without @). Sorted alphabetically.
#  - Optionally specify platform: `platform:username` (e.g., `github:mitchellh`).
#  - To denounce a user, prefix with minus: `-username` or `-platform:username`.
#  - Optionally, add details after a space following the handle.
#
# Maintainers can vouch for new contributors by commenting "lgtm" on an
# issue by the author. Maintainers can denounce users by commenting
# "denounce" or "denounce [username]" on an issue or PR.
mitchellh
-github:badguy
-github:slopmaster3000 Submitted endless amounts of AI slop

Man kann damit Leuten nicht nur vertrauen, sondern auch explizit misstrauen. Mitchell liefert dazu noch passende GitHub-Actions, mit denen PRs direkt kategorisiert und ggf. geschlossen werden können.

Wenn das was größeres wird, könnte man daraus auch so ein Web-Of-Trust wie bei GPG bauen. Mal gucken, was damit passiert.

Man kennt den .well-known-Ordner ja hauptsächlich von den ACME-Challenges bei LE-Zertifikaten / dem ACME-Protokoll. Da liegen auch ein paar andereSachen, wie JWKS/OIDC-Daten.

Gerade mal geschaut, was da sonst noch so drin liegt. Wikipedia hat eine Liste. Da springt mir ins Auge: change-password: Helps password managers find the URL for changing client account passwords

Können wir da sauch für die Accountlöschung machen? Und DSGVO-Auskünfte?

Maybe the Default Settings Are Too High

The Inner Workings of JavaScript Source Maps.

Ich hab ja schonmal einen Guide für Dokumentationen verlinkt. Hier ist auch noch eine eher praktischere Ergänzung: What nobody tells developers about documentation

Diátaxis: A systematic approach to technical documentation authoring. In Aktion kann man das sehr gut in der Doku von Astro beobachten.