Files
werkator/docs/prs
mhoennigandClaude Fable 5 89de3e0378 Step 21 session A: close step 17's paperwork
- PR-docs get their real numbers: bwrap-build-runtime -> PR#4,
  build-current-head-from-the-branches-view -> PR#3 (files and scenario IDs)
- tools/remote: header note marking install's clone step and build as the
  self-build prototype, superseded by session D of step 21 (usage range grown)
- ADR 0008: bubblewrap user-namespace sandbox as the third build runtime;
  step 17 and the plan README now point at 0008 (0007 was taken by build
  definitions before the step landed)
- AGENTS.md: decisions list catches up with ADR 0007 and ADR 0008
- architecture skill: BwrapBuildRunner paragraph (rootfs unpack, uid mapping,
  mount ordering, pinned keys) and the dispatcher's three-way routing
- plan README: step 21 entry now describes the werkdock/ subdirectory path

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-09-01 06:21:29 +02:00
..

Pull-Request Documentations in doc/PR

This directory contains documentation for each pull request (PR).

IMPORTANT: The PR-documentation documents the change which was applied in that PR. Such documentation might be outdated right after the next PR was merged. Historic PR-documentation is not maintained along with new PRs.

Naming Convention

YYYY-MM-DD-PR#999-short-description-of-pr

  1. Date of the PR in the format YYYY-MM-DD
  2. followed '-PR#' followed by the number of the pull request in GitEA,
  3. a short description of the PR with dashes between the words,
  4. '.md'

Yes, to get the PR-number, you need to open a pull request first, but initially prefix its title with WIP: to mark it as a work in progress until it is ready for review.

Guidelines

  • Documentations must be written in Markdown format.
  • Use Englisch, it's a public open source project.
  • Use clear and concise language and keep it short.
  • Include relevant details and context, explain the "why".
  • Mark reference to Taiga or any other tool that is not public as "Hostsharing-internal".
  • If necessary, copy important parts of the ticket description.
  • One sentence or statement per line to make diffs easier to read.

Structure

The main (##) sections have to appear in exactly this order, omitting sections which do not apply:

  1. Related Links (optional)
  2. The Problem (required)
  3. Non-Goals (required)
  4. The Scenarios (optional for maintenance or bug fixing PRs, required for features)
  5. The Solution (required)
  6. Open Questions (optional)
  7. Additional Changes (optional)
  8. Prerequisite PRs (optional)
  9. Follow-up PRs (optional)
  10. Attachments (optional)

For details, see template