Agent Project Protocol v4

A universal guide for Agents and Operators. Describes how project folders are structured, which files are mandatory, how JACK_IN/JACK_OUT function as pre-flight and post-session instruments, and how Git/Forgejo features (Issues, Wiki, Milestones, Labels) integrate into the workflow.

Note: This paper uses the generic terms Operator (human project partner) and Agent (AI assistant). In a real project folder, these are replaced by the actual names of the team members.

Traffic-light legend: 🔴 Mandatory · 🟡 Optional, project-dependent · 🟢 Recommended / Nice-to-have

What's new in v4: Git-native workflow · Issues replace backlog.md · Wiki for documentation · Milestones & Labels for structure · JACK_IN/JACK_OUT include Issues & Wiki · CLI guide for Operators · API guide for Agents · Language toggle (EN/DE)

---

Why project folders?

Projects grow. Without structure, chaos ensues: files pile up flat, nobody knows what's current, decisions aren't traceable, new agents can't find their bearings. A fixed folder structure with clearly defined files solves this:

• Onboarding: A new agent reads JACK_IN.md and knows exactly which files to load and in what order
• Re-entry: After a break, open Issues and the latest session protocol deliver the current state immediately
• Traceability: decision-log.md explains why something is the way it is – not just what it is
• Clean closure: JACK_OUT.md ensures nothing is forgotten, including testing docs

---

🔴 Folder structure (Standard)

This folder structure represents a concept, not a constraint. Folders 10, 20 and 99 are strongly recommended. The agent should adapt the folder structure and naming to the project.

Numeric ordering

The folders use numeric ordering with deliberately placed gaps. The principle:

• Lower number = higher priority/importance – 10_docs/ is more important than 80_security/
• Gaps are a feature, not a bug – The jumps leave room for future folders
• Tens-steps as standard, fives for closely related folders (e.g. 10_docs/ → 15_dev/)
• 99_ is reserved for archive/end

project-name/
├── README.md              ← Project overview (rendered by Forgejo)
├── JACK_IN.md             ← Pre-flight: reading order for full context
├── JACK_OUT.md            ← Post-session checklist
├── INDEX.md               ← Current structure + live status (auto-updated)
├── spec.md                ← Full specification (optional for small projects)
├── 10_docs/               ← Documentation
│   ├── decision-log.md    ← Engineering journal (Why?) — stays in Git
│   └── sessions/          ← Session protocols (template + per-session files)
├── 15_dev/                ← Development & Setup
├── 20_testing/            ← Test matrix, bug log, error matrix
├── 30_stakeholders/       ← External parties
├── 40_deploy/             ← Deployment processes, scripts
├── 80_security/           ← Security docs, hardening, incidents
├── 98_backups/            ← Backups (read-only, recovery only)
└── 99_archive/            ← Completed, old, deprecated

What changed from v3?

v3	v4	Why
10_docs/backlog.md	Forgejo Issues	Issues have discussion threads, labels, milestones, assignees, status tracking
kanban-backlog.md (Obsidian)	Forgejo Project Boards (Web-UI)	Native Kanban in Forgejo, no plugin needed
Documentation in 10_docs/	Forgejo Wiki (optional)	Wiki for concept docs, guides, research notes. Repo stays focused on code
Flat .md files for tracking	Milestones + Labels	Structured filtering, grouping, and progress tracking

Which folders and files are mandatory?

Folder / File	Required	Purpose
README.md	🔴 Always	Project overview, entry point, team, infra
JACK_IN.md	🔴 Always	Pre-flight: ordered reading list + Issue/Wiki check
JACK_OUT.md	🔴 Always	Post-session checklist incl. Issue/Wiki sync
INDEX.md	🔴 Always	Current folder structure + live status table
10_docs/decision-log.md	🔴 Always	Technical decisions + rationale — stays in Git
10_docs/sessions/_template.md	🔴 Always	Session protocol template
10_docs/sessions/	🔴 Always	Session protocols (dedicated folder)
20_testing/	🟡 When testing needed	Test matrix, bug log, error matrix
spec.md	🟡 Larger projects	Full specification
15_dev/	🟡 Projects with setup/code	Installation guides, config references
30_stakeholders/	🟡 External parties	One subfolder per stakeholder
40_deploy/	🟡 Deployment projects	Deploy scripts, update processes
80_security/	🟡 Security-relevant projects	Hardening, incidents, monitoring
98_backups/	🟢 Optional	Backups, read-only
99_archive/	🟡 Projects with history	Old versions, completed topics

Note: 10_docs/backlog.md is replaced by Forgejo Issues. If a backlog.md exists from v3, it should be marked as "Migrated to Issues" and is no longer maintained.

---

🔴 Git-Native Workflow – Issues, Wiki, Milestones, Labels

Issues — The new Backlog

Issues replace backlog.md as the primary tracking system. Each backlog item becomes an Issue.

Standard Labels

Label	Color	Purpose
critical	🔴 #b91c1c	Must solve before blocker / go-live
important	🟡 #eab308	Should solve soon
nice-to-have	🟢 #22c55e	Long-term
bug	#ef4444	Bug / error
feature	#3b82f6	New feature / function
infra	#8b5cf6	Infrastructure / deployment
security	#dc2626	Security / hardening
docs	#6b7280	Documentation
org	#06b6d4	Organisation / structure / user-management
done-archived	#9ca3af	Completed (used for migrated historical items)

Milestones

Milestones group Issues into deliverable phases. Examples:

• "Security Hardening" — all M1-M12 security items
• "Lucy Integration" — all Lucy-related tasks
• "Phase 1: Core" — first deliverable

Issue Body Convention

Every Issue body should contain:

## Description

What needs to be done and why.

## Context

References to decisions (DL-XXX), sessions, or external docs.

## Acceptance Criteria

- [ ] Criterion 1
- [ ] Criterion 2

## Migrated from

`10_docs/backlog.md` (if applicable)

Assignment

Issues are assigned to team members:

• Operator — physical infra, approvals, external accounts
• Agent — documentation, config, scripts, automation
• Together — planning, decisions, reviews

Closed Issues as History

Completed items are closed (not deleted). This preserves:

• When it was done
• Who did it
• Discussion context
• Links to commits that resolved it

Wiki — Documentation that's not Code

The Forgejo Wiki is for documentation that doesn't need code review or commit-versioning:

What goes into the Wiki

Content	Why Wiki	Example
Architecture docs	No code review needed	Stack overview, component map
Setup guides	Step-by-step, not code	Installation, configuration
Research notes	One-time reference	Evaluation of tools, comparison
Playbooks	Operational reference	How to handle X when Y happens
Doku-Plan	Meta-documentation	Where is what documented

What stays in the Repo

Content	Why Git	Example
Decision Log	Permanent journal, needs git blame	decision-log.md
Session protocols	Versioned with code state	sessions/
Code	Obviously	.py, .sql, .yml, Dockerfiles
Configs	Version-controlled	.env.example, init.sql
INDEX.md	Repo structure snapshot	Auto-generated at JACK_OUT

Project Boards (Kanban) — Web-UI only

Forgejo Project Boards are available in the Web-UI for visual Kanban. The API does not yet support them (Forgejo Discussion #466).

Current status:

• ✅ Create boards, columns, move issues in Web-UI
• ❌ API access not available yet
• Workaround: Agent works with Issues + Labels + Milestones via API. Operator manages board visually.

---

🟡 Tags & Frontmatter – Obsidian searchability

Every file in the project folder should use Obsidian tags to ensure searchability. Tags belong in the frontmatter (YAML) at the top of the file.

Convention

---
tags:
  - project-name
  - <document-type>
---

Rules

• Project name as root tag – Every file carries the project name as its first tag
• Document type as second tag – decision-log, session, overview, spec, testing
• Lowercase, kebab-case – decision-log, not DecisionLog
• Session protocols always get session as document-type tag

---

🔴 JACK_IN.md – The Pre-Flight

The JACK_IN.md is the reading order an agent follows at session start. It's not a general "read the README" — it's an explicit, numbered list of files to load into context, in order.

Mandatory contents

1. Numbered reading list — files in order, grouped by priority
2. Session protocol — "read the latest session protocol" as a step
3. Open Issues — "check open Issues in the Forgejo repo" as a mandatory step
4. Testing docs — 20_testing/ files as mandatory reads
5. Wiki — "check Wiki for architecture/guides" as a step
6. External context — references to FACTS.md, TOOLS.md, other wikis (at need)
7. Rules — "don't skip", "maintain order", "confirm context loaded before working"

Example structure

1. JACK_IN.md (this file)
2. INDEX.md — current structure + live status
3. 10_docs/architektur.md — stack, components (or Wiki → Architecture)
4. 10_docs/decision-log.md — all decisions, why
5. Forgejo Issues — open issues, filtered by milestone/label
6. 20_testing/test-matrix.md — test cases, status
7. 20_testing/bug-log.md — known bugs
8. 20_testing/error-matrix.md — error codes
9. 10_docs/sessions/ — latest session protocol
10. Forgejo Wiki — architecture, guides, research notes
11. External (at need): FACTS.md, TOOLS.md, PLAYBOOK.md

Rules

• JACK_IN.md is sparingly modified — only when new fundamental documents are added
• Issues are mandatory — check open issues before starting work. Filter by milestone for current focus.
• Wiki is mandatory — check for architecture docs, guides, research notes before assuming
• Testing docs are mandatory reads — not optional
• Session protocol is mandatory — the latest protocol shows what was done and what's open
• After reading: briefly confirm context loaded, then start working

---

🔴 JACK_OUT.md – The Post-Session

The JACK_OUT.md is the checklist worked through at session end. It ensures all documents are updated and re-entry works cleanly next time.

Steps

#	Step	Required	Purpose
1	Session protocol — update 10_docs/sessions/YYYY-MM-DD_sessionN.md	🔴 Always	Document the session
2	Issues — close completed, create new, update descriptions	🔴 Always	Sync issue tracker
3	Decision-Log — new DL-XXX entries if decisions were made	🟡 New decisions	Only if something was decided
4	JACK_IN.md — sync only if new fundamental documents were added	🟡 On changes	Update reading list
5	Architecture/Spec — update if architecture changed (Wiki or repo)	🟡 On changes	Keep technical docs current
5b	Testing docs — 20_testing/ (test-matrix, bug-log, error-matrix)	🔴 When near bugs/tests	Keep testing docs current
6	INDEX.md — regenerate: folder structure, live status, DL overview	🔴 Always	Current snapshot
7	Wiki — update if documentation changed	🟡 On changes	Keep Wiki current
8	External references — FACTS.md, TOOLS.md, MEMORY.md	🟡 As needed	Sync external docs
9	Daily log — update workspace daily log	🔴 Always	Agent's daily protocol
10	Git — commit + push	🔴 Always	Version control
11	Final check — everything checked off? Set session to "completed"	🔴 Always	Clean closure

Order matters

Session end signal
  ↓
1. Session protocol
2. Issues (close/create/update)
3. Decision-Log [if new decisions]
4. JACK_IN [if new fundamental docs]
5. Architecture/Spec [if changes]
5b. Testing docs [if near bugs/tests]
6. INDEX.md (regenerate)
7. Wiki [if docs changed]
8. External references [as needed]
9. Daily log
10. Git commit + push
11. Final check
  ↓
Session closed

Rules

• Pflicht-Schritte können nicht übersprungen werden — 1, 2, 5b, 6, 9, 10, 11 are always executed
• Issue sync is mandatory — close what's done, create what's new, update what changed
• 5b is not optional when you touched bugs or tests — forgetting testing docs is the #1 cause of repeated work
• INDEX.md is regenerated at every JACK_OUT — it's the current snapshot
• Wiki sync when docs changed — architecture, guides, research notes
• Git: always commit, never leave uncommitted changes

---

🔴 Session Protocol — Template

The session protocol is the most important document for continuity. It's a checklist, not a narrative.

Template (v3)

# Session XX – YYYY-MM-DD (Weekday, time)

> Short description

---

## Open Issues (from Forgejo, auto-transferred)

> Quick summary of open issues relevant to this session.
> Full detail: see Forgejo Issue tracker.

### Milestone: [Name]
- #NN Issue title — status
- #NN Issue title — status

### Other
- #NN Issue title — status

## This Session — Checklist

> What was done / is being done in this session.

- [x] Completed task
- [ ] Open task

## Decisions This Session

| DL | Thema | Status |
|----|-------|--------|
| DL-XXX | Description | 🟢/🟡/⛔ |

## Abschluss

> Filled at JACK_OUT or manual finalization.

- [x] Done: ...
- [ ] Remaining: ...
- [ ] New: ... (create Issues in Forgejo)

> [!NOTE] Notes, references, learnings

What changed from v3?

• Task-Groups replaced by Issues — instead of maintaining task-groups in the session protocol, reference open Issues from Forgejo
• "Open Issues" section — quick summary of relevant open issues, grouped by milestone
• Abschluss: "New" → create Issue — instead of adding to a task-group, create a Forgejo Issue

Rules

• Checklist, not narrative — - [x] / - [ ], no atmosphere
• Reference Issues, don't duplicate — "#42" instead of copying the issue text
• Hint blocks — > [!NOTE] for metadata, optional
• Short — guide and anchor, not more. Details go in DL, Issues, or Wiki
• Context-sparing — every session protocol is read at JACK_IN. Unnecessary text costs tokens

---

🔴 Decision-Log — Why, not just What

The decision-log.md is the most important document for traceability. It stays in Git — it's a permanent journal that benefits from version control.

Why Decision-Log stays in Git (not Issues or Wiki)

• Sequential and permanent — Decisions don't get "closed", they get superseded
• git blame — see exactly when and by whom a decision was added
• History — the full decision chain is preserved in commit history
• No discussion needed — Decisions are documented, not discussed (that happens in the session)

Format

## DL-XXX: Title

**Proposed by:** Operator / Agent / Team
**Date:** YYYY-MM-DD
**Status:** 🟢 Decided / 🟡 In Discussion / ❌ Rejected / ⛔ Superseded by DL-YYY

**Context:** Why do we need to decide?

**Decision:** What was decided?

**Reason:**
1. First reason
2. Second reason

**Rejected:**
- Option A → Why not
- Option B → Why not

Rules

• Sequential numbering: DL-001, DL-002, ... Never reuse numbers
• Old entries stay, are not deleted
• Status changes to ⛔ Superseded by DL-YYY when overridden
• New entry carries "(supersedes DL-XXX)" in title
• This creates a complete decision history

---

🟢 SOT Principle – Single Source of Truth

Learned the hard way: Without a dedup rule, you end up with 5 documents about the same topic, nobody knows which is current.

Rule

Before creating a new document about a topic, check if one already exists:

1. Search first — look for an existing document (in repo, Wiki, or Issues)
2. If found: update the existing document, don't create a new one
3. If not found: create new + add to INDEX / file overview
4. One document per topic — no duplicates

Where things live (v4)

Content type	Location	Why
Code	Repo	Version-controlled, reviewed
Decisions	Repo (decision-log.md)	Permanent journal, git blame
Session protocols	Repo (sessions/)	Versioned with code state
Architecture docs	Wiki	No code review needed, easy to update
Setup guides	Wiki	Step-by-step reference, not code
Research notes	Wiki or 99_archive/	One-time reference
Open tasks	Issues	Discussion, tracking, assignment
Bugs	Issues (label: bug)	Discussion, tracking, resolution
Configs	Repo	Version-controlled

---

🔴 Change Approval Process

No-silent-changes is the core principle.

Change Request
 │
 ▼
 Proposal ────▸ Formulate what, why, impact (can be an Issue)
 │
 ▼
 Review ──────▸ Impact analysis, feasibility check
 │
 ▼
 Approval ────▸ Approval (Operator)
 │
 ▼
 Implement ───▸ Execution
 │
 ▼
 Document ────▸ Decision-Log + Session Protocol + Issue close

Principles

• A mentioned topic is not an implementation order
• Proposal-based workflow: First proposal, then discussion, then approval, then implementation
• Every change is documented
• Pro tip: Create a Forgejo Issue for the change proposal. Discussion happens in the Issue. Decision goes to decision-log.md. Issue is closed when implemented.

---

🔴 Documentation Mandate

Documentation happens parallel to implementation, not afterwards.

Document	When to write	Where
decision-log.md	On every technical decision	Repo
Issues	Continuously, on new insights	Forgejo Issues
Session protocol	During and at end of session	Repo
test-matrix.md	When tests are run or created	Repo
bug-log.md	When bugs are found or fixed	Repo (+ Issue)
INDEX.md	At every JACK_OUT (regenerate)	Repo
Wiki pages	When architecture/guides change	Forgejo Wiki

---

🟡 Multi-Agent & Roles

Projects are teamwork between Agent and Operator. Typically 1:1. For multi-agent projects, extended rules apply.

Single-Agent (Standard)

One Agent + one Operator. ~80% of tasks done together.

Multi-Agent (extended)

Role	Responsibility	Documented in
Lead Agent	Coordinates, owns Issues, runs JACK_OUT	README team table
Specialist Agent	Works assigned areas, documents in own session protocol	README team table + Issue assignment
Operator	Approvals, physical infra, external accounts	README team table

Rules for Multi-Agent

• One agent owns the Issues — only the Lead Agent creates/closes Issues
• Decision-Log is shared — all agents can create DL entries, Lead Agent reviews
• Session protocols are separate — YYYY-MM-DD-<topic>-<agent>.md
• JACK_OUT runs with the Lead Agent — only the Lead Agent performs synchronization
• Conflict rule: If two agents work on the same thing → Lead Agent decides, Operator has veto

---

🔴 Assignment – Who does what

Every task, decision, and change should make clear who is responsible.

In Issues

Issues are assigned to team members via the Forgejo assignee field.

In the decision-log

## DL-003: AlmaLinux 10 as OS
**Proposed by:** Operator

Assignment principles

• Together (Operator + Agent): Planning, decisions, reviews, complex setups
• Operator: Physical infra, external accounts, approvals, hardware
• Agent: Documentation, monitoring, config, scripts, automation
• Explicit attribution: If an idea clearly comes from one person → document by name
• No unexplained decisions: Every DL must have at least one originator

---

🟢 Templates – intentionally minimal

The session protocol template (_template.md) is the only copy-paste template. Everything else is a concept, not a corset.

• Every project is different — templates tempt you to fill empty sections you don't need
• The formats in this paper are descriptions, not prescriptions
• If you need a template, build one from the examples here

---

🟢 Tips for Agents

• JACK_IN first — load context before acting, don't guess
• Check Issues — open issues are the work queue, always check before starting
• Check Wiki — architecture docs and guides live there now
• JACK_OUT is mandatory — work through checklist, don't skip
• Proposal-first — no changes without approval
• SOT Principle — search before creating, update instead of duplicating
• Testing docs are not optional — read them at JACK_IN, update them at JACK_OUT
• Archive, don't delete — old files go to 99_archive/
• Attribution — every task, decision, and change shows who's responsible
• Superseding — old decisions are marked ⛔ Superseded, not deleted
• One Issue per task — don't bundle unrelated items in a single Issue

---

🟢 Tips for Operators

• The Web-UI is your friend — Forgejo's Web-UI gives you Issues, Boards, Wiki, Milestones visually
• Issues are your tracking tool — if it's not an Issue, it doesn't exist
• Milestones for planning — group Issues into milestones for phases
• Labels for filtering — use labels to find "all critical security issues" quickly
• Wiki for reading — architecture and guides are in the Wiki, not hidden in folders
• Boards for overview — create a Project Board for visual Kanban (Web-UI only)

---

🟡 Migration Obsidian → Git/Forgejo

When a project migrates from Obsidian to a Git repository, the folder structure transfers directly.

What transfers 1:1

• Complete folder structure
• Core files (JACK_IN, JACK_OUT, decision-log, sessions)
• Frontmatter (YAML) — displayed by Forgejo, doesn't interfere
• README.md — Forgejo renders it automatically

What changes in v4

Obsidian/v3 feature	v4 replacement	How
backlog.md	Forgejo Issues	Migrate each item as an Issue with labels + milestone
kanban-backlog.md (plugin)	Forgejo Project Board	Create board in Web-UI
Wikilinks [[README]]	Relative links	[README](../README.md)
.obsidian/ folder	.gitignore	Exclude
Architecture in 10_docs/	Forgejo Wiki	Move to Wiki, keep redirect note

Migration steps

1. Create labels in the repo (or use the standard set)
2. Create milestones
3. Migrate each backlog.md item as an Issue (open + closed for history)
4. Create a Project Board in Web-UI (optional)
5. Move documentation files to Wiki (optional)
6. Update backlog.md → "Migrated to Issues"
7. Update JACK_IN.md and JACK_OUT.md to include Issues/Wiki steps
8. Commit and push

---

🔴 Git Guide for Operators (CLI)

Git is the version control system. Forgejo is the platform. The Operator interacts with Git via CLI on their local machine.

Setup (one-time)

# Configure your identity
git config --global user.name "Your Name"
git config --global user.email "your@email.com"

# Store credentials (so you don't type them every time)
git config --global credential.helper store

Daily operations

# Clone a repo (one-time per project)
git clone https://git.example.com/org/repo.git

# Pull latest changes (before starting work)
git pull

# Check what changed
git status
git diff

# Stage and commit changes
git add <file-or-folder>
git commit -m "Description of what changed"

# Push to remote
git push

# Create a feature branch
git checkout -b feature/new-feature

# Switch back to main
git checkout main

# Merge a branch
git checkout main
git merge feature/new-feature

# Delete a branch after merge
git branch -d feature/new-feature

Commit message conventions

type: short description

type can be:
- feat: new feature
- fix: bug fix
- docs: documentation
- infra: infrastructure
- refactor: code change that neither fixes a bug nor adds a feature
- chore: maintenance

Example: feat: add SMTP configuration to Forgejo

Things to know

• git pull before git push — always pull first to avoid conflicts
• .gitignore — files listed here are not tracked (e.g. .env, .obsidian/)
• Never commit secrets — passwords, tokens, keys go in .env (which is in .gitignore)
• Commits are history — once pushed, they're permanent. Think before you commit.
• Branches for experiments — create a branch, experiment, merge or discard

---

🔴 Git Guide for Agents (API)

The Agent interacts with Forgejo via the REST API. This allows Issue management, label/milestone creation, and repo operations without a browser.

Authentication

# Basic auth (username + password)
curl -u "username:password" "https://git.example.com/api/v1/..."

# Token auth (if API tokens work)
curl -H "Authorization: token <TOKEN>" "https://git.example.com/api/v1/..."

Issues

# List open issues
curl -u "user:pass" "https://git.example.com/api/v1/repos/org/repo/issues?state=open"

# Create an issue
curl -X POST -u "user:pass" \
  -H "Content-Type: application/json" \
  "https://git.example.com/api/v1/repos/org/repo/issues" \
  -d '{
    "title": "Issue title",
    "body": "Description",
    "labels": [1, 2],
    "milestone": 1,
    "assignees": ["username"]
  }'

# Close an issue
curl -X PATCH -u "user:pass" \
  -H "Content-Type: application/json" \
  "https://git.example.com/api/v1/repos/org/repo/issues/42" \
  -d '{"state": "closed"}'

# Add a comment
curl -X POST -u "user:pass" \
  -H "Content-Type: application/json" \
  "https://git.example.com/api/v1/repos/org/repo/issues/42/comments" \
  -d '{"body": "Update: working on this now"}'

Labels

# List labels
curl -u "user:pass" "https://git.example.com/api/v1/repos/org/repo/labels"

# Create a label
curl -X POST -u "user:pass" \
  -H "Content-Type: application/json" \
  "https://git.example.com/api/v1/repos/org/repo/labels" \
  -d '{"name": "critical", "color": "#b91c1c", "description": "Critical priority"}'

Milestones

# List milestones
curl -u "user:pass" "https://git.example.com/api/v1/repos/org/repo/milestones"

# Create a milestone
curl -X POST -u "user:pass" \
  -H "Content-Type: application/json" \
  "https://git.example.com/api/v1/repos/org/repo/milestones" \
  -d '{"title": "Phase 1: Core", "description": "Core functionality"}'

Wiki

# Wiki is not available via API in Forgejo 16.
# Use the Web-UI for Wiki editing.
# Alternative: write wiki content as Markdown files, commit to a wiki branch.

Repo operations

# List repos in an org
curl -u "user:pass" "https://git.example.com/api/v1/orgs/homelab/repos"

# Get repo info
curl -u "user:pass" "https://git.example.com/api/v1/repos/org/repo"

# Get file content
curl -u "user:pass" "https://git.example.com/api/v1/repos/org/repo/contents/path/to/file"

Important notes for Agents

• Profile picture: Ensure your commits are linked to your Forgejo account. The email in git config must match an email registered in your Forgejo account.
• Multiple emails: Forgejo matches commits by email. If you use different emails, add all of them to your Forgejo account.
• Issues are the work queue: Always check open Issues at JACK_IN. Close Issues at JACK_OUT.
• Wiki limitation: The API doesn't support Wiki in Forgejo 16. Use Web-UI or keep docs in the repo.
• Be gentle with the API: Don't hammer it. Batch operations where possible.

---

🟢 Language Toggle

This document is available in two languages:

Language	File
English	README.md
Deutsch	README.de.md

Both versions are kept in sync. If you find a discrepancy, the English version is authoritative.

---

Changelog

Version	Date	Changes
v1	2026-08-09	Initial release
v2	2026-08-09	Multi-agent, Kanban, Obsidian migration
v3	2026-08-16	JACK_IN/JACK_OUT replace README/CLOSEME · Task-Groups · Session template with persistent open tasks · Testing as mandatory step · SOT Rule · 5b Testing docs in JACK_OUT
v4	2026-08-17	Git-native workflow: Issues replace backlog.md · Wiki for documentation · Milestones & Labels · JACK_IN/JACK_OUT include Issues & Wiki · CLI guide for Operators · API guide for Agents · Project Boards (Web-UI) · Session protocol references Issues instead of task-groups

---

Updated: 2026-08-17 · v4 · Branch: v4-git-workflow