Promote vergabe-teilnahme capability after SCOPE.md fill-in (T05 entry 2).

SCOPE.md was already filled; update the registry entry to D3/A1/C1/R1,
document issue-core and whynot-design relations, and align the index vector
with the authored scope and wiki evidence.

.claude/rules/credential-routing.md

@@ -0,0 +1,50 @@
+# Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=vergabe-teilnahme` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`

.claude/rules/first-session.md

@@ -1,11 +1,11 @@
 ## First Session Protocol
 
-Triggered when `get_domain_summary("vergabe_teilnahme")` shows **no workstreams**.
+Triggered when `get_domain_summary("communication")` shows **no workstreams**.
 The project is registered but work has not yet been structured.
 
 **Step 1 — Read, don't write**
-- `~/the-custodian/canon/projects/vergabe_teilnahme/project_charter_v0.1.md` — purpose, scope
-- `~/the-custodian/canon/projects/vergabe_teilnahme/roadmap_v0.1.md` — planned phases
+- `~/the-custodian/canon/projects/communication/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/communication/roadmap_v0.1.md` — planned phases
 - Scan repo root: README, directory structure, existing code or docs
 
 **Step 2 — Survey in-progress work**
@@ -17,20 +17,20 @@ roadmap phase. **Wait for approval before creating.**
 
 **Step 4 — Create workplan file first, then DB record (ADR-001)**
 ```
-workplans/vergabe_teilnahme-WP-NNNN-<slug>.md   ← write this first
+workplans/WP-NNNN-<slug>.md   ← write this first
 ```
 Then register in the hub:
 ```
-create_workstream(topic_id="7d4d3e35-312f-4723-bde9-ddb43799109e", title="...", owner="...", description="...")
+create_workstream(topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc", title="...", owner="...", description="...")
 create_task(workstream_id="<id>", title="...", priority="high|medium|low")
 ```
 
 **Step 5 — Record the setup**
 ```
 add_progress_event(
-    summary="First session: structured vergabe_teilnahme into N workstreams, M tasks",
+    summary="First session: structured communication into N workstreams, M tasks",
     event_type="milestone",
-    topic_id="7d4d3e35-312f-4723-bde9-ddb43799109e",
+    topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc",
     detail={"workstreams": [...], "tasks_created": M}
 )
 ```

.claude/rules/repo-identity.md

@@ -1,5 +1,5 @@
-**Purpose:** Django 6 + Tailwind + HTMX bid management app
+**Purpose:** Coulomb project repository (bootstrapped from repo-seed template)
 
-**Domain:** vergabe_teilnahme
-**Repo slug:** vergabe_teilnahme
-**Topic ID:** 7d4d3e35-312f-4723-bde9-ddb43799109e
+**Domain:** communication
+**Repo slug:** vergabe-teilnahme
+**Topic ID:** 36c7421b-c537-4723-bf75-42a3ebc6a1dc

.claude/rules/session-protocol.md

@@ -1,6 +1,7 @@
 ## Session Protocol
 
-State Hub: http://127.0.0.1:8000
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
 
 **Step 1 — Orient**
 
@@ -10,7 +11,7 @@ cat .custodian-brief.md
 ```
 Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
 ```
-get_domain_summary("vergabe_teilnahme")
+get_domain_summary("communication")
 ```
 If MCP tools are unavailable in the current agent session, use the REST API:
 ```bash
@@ -21,14 +22,14 @@ If the hub is offline: `cd ~/state-hub && make api`
 **Step 2 — Check inbox**
 With MCP tools:
 ```
-get_messages(to_agent="vergabe_teilnahme", unread_only=True)
+get_messages(to_agent="vergabe-teilnahme", unread_only=True)
 ```
 Mark read with `mark_message_read(message_id)`. Reply or act on coordination
 requests before proceeding.
 
 Without MCP tools:
 ```bash
-curl -s "http://127.0.0.1:8000/messages/?to_agent=vergabe_teilnahme&unread_only=true" \
+curl -s "http://127.0.0.1:8000/messages/?to_agent=vergabe-teilnahme&unread_only=true" \
   | python3 -m json.tool
 curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
   -H "Content-Type: application/json" -d '{}'
@@ -39,12 +40,12 @@ curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
 ls workplans/
 ```
 For each file with `status: ready`, `active`, or `blocked`, note pending
-`todo`/`in_progress` tasks.
+`wait`/`todo`/`progress` tasks.
 
 **Step 4 — Present brief**
 
-1. **Active workstreams** for `vergabe_teilnahme` — title, task counts, blocking decisions
-2. **Pending tasks** from `workplans/` + any `[repo:vergabe_teilnahme]` hub tasks
+1. **Active workstreams** for `communication` — title, task counts, blocking decisions
+2. **Pending tasks** from `workplans/` + any `[repo:vergabe-teilnahme]` hub tasks
 3. **Goal guidance** — if `goal_guidance` in summary:
    - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
    - `alignment_warnings`: flag if active work is not aligned with current goal
@@ -61,23 +62,23 @@ If no workstreams: follow First Session Protocol (`first-session.md`).
 **Session close:**
 With MCP tools:
 ```
-add_progress_event(summary="...", topic_id="7d4d3e35-312f-4723-bde9-ddb43799109e", workstream_id="<uuid>")
+add_progress_event(summary="...", topic_id="36c7421b-c537-4723-bf75-42a3ebc6a1dc", workstream_id="<uuid>")
 ```
 Without MCP tools:
 ```bash
 curl -s -X POST http://127.0.0.1:8000/progress/ \
   -H "Content-Type: application/json" \
-  -d '{"topic_id":"7d4d3e35-312f-4723-bde9-ddb43799109e","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
+  -d '{"topic_id":"36c7421b-c537-4723-bf75-42a3ebc6a1dc","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
 ```
 If workplan files were modified, ensure the local copy is up to date first:
 ```bash
 git -C <repo_path> pull --ff-only
-cd ~/state-hub && make fix-consistency REPO=vergabe_teilnahme
+cd ~/state-hub && make fix-consistency REPO=vergabe-teilnahme
 ```
 For repos where implementation runs on a remote machine (e.g. CoulombCore),
 use the combined target which pulls before fixing:
 ```bash
-cd ~/state-hub && make fix-consistency-remote REPO=vergabe_teilnahme
+cd ~/state-hub && make fix-consistency-remote REPO=vergabe-teilnahme
 ```
 **C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
 will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes

.claude/rules/stack-and-commands.md

@@ -1,32 +1,19 @@
 ## Stack
 
-- **Language:** Python 3.12 (Django 6), Node 22 (Vite + Tailwind v4)
-- **Key deps:** Django, htmx, Alpine.js, Tailwind v4, whynot-design (vendored
-  under `static/src/vendor/whynot-design/`)
+<!-- TODO: Fill in language, frameworks, and key dependencies -->
+- **Language:**
+- **Key deps:**
 
 ## Dev Commands
 
 ```bash
+# TODO: Fill in the standard commands for this repo
+
 # Install dependencies
-uv sync                     # Python
-npm ci                      # Node (Vite/Tailwind)
 
-# Run dev stack
-make db                     # Start postgres if not running
-make dev                    # Django runserver on :9000
-make css                    # Tailwind/Vite watcher (rebuilds main.css)
+# Run tests
 
-# Build CSS bundle for prod / for verification
-npm run build               # → static/dist/main.css
+# Lint / type check
 
-# Re-vendor the whynot-design system from a pinned upstream commit
-make sync-whynot-design     # reads .whynot-design-ref by default
-                            # or: ./scripts/sync-whynot-design.sh <ref>
-
-# Tests / lint
-make test                   # uv run pytest
-make lint                   # ruff + mypy
+# Build / package (if applicable)
 ```
-
-See `wiki/DesignSystem.md` for the whynot-design adoption status (Phase 1
-tokens+CSS done; Phase 2 components deferred) and local style conventions.

.claude/rules/workplan-convention.md

@@ -1,7 +1,7 @@
 ## Workplan Convention (ADR-001)
 
-File location: `workplans/vergabe_teilnahme-WP-NNNN-<slug>.md`
-ID prefix: `VERGABE_TEILNAHME-WP`
+File location: `workplans/WP-NNNN-<slug>.md`
+ID prefix: `WP-`
 
 Work items originate as files in this repo **before** being registered in the hub.
 
@@ -12,7 +12,7 @@ repo state, and `finished` when implementation is complete. `stalled` and
 `needs_review` are derived health labels, not stored statuses.
 
 Closed workplans may be moved to `workplans/archived/` with a completion-date
-prefix: `YYMMDD-vergabe_teilnahme-WP-NNNN-<slug>.md`. The frontmatter id remains
+prefix: `YYMMDD-WP-NNNN-<slug>.md`. The frontmatter id remains
 unchanged; the prefix is only for quick visual reference.
 
 Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
@@ -21,8 +21,20 @@ Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**
 directly. Promote anything requiring analysis, design, approval, dependencies, or
 multiple planned phases into a normal workplan.
 
-Ecosystem todos from other agents arrive as `[repo:vergabe_teilnahme]` hub tasks —
+Ecosystem todos from other agents arrive as `[repo:vergabe-teilnahme]` hub tasks —
 visible at session start. Pick one up by creating the workplan file, then registering
 the workstream.
 
+Task blocks use this shape:
+
+```task
+id: WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
 <!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

.repo-classification.yaml

@@ -0,0 +1,19 @@
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-06-22'
+  classified_by: agent
+  category: experimental
+  domain: communication
+  secondary_domains: []
+  capability_tags:
+  - marketplace
+  - collaboration
+  - procurement
+  - governance
+  business_stake:
+  - product
+  - sales
+  business_mechanics:
+  - coordination
+  - operation

AGENTS.md

@@ -2,12 +2,12 @@
 
 ## Repo Identity
 
-**Purpose:** Django 6 + Tailwind + HTMX bid management app
+**Purpose:** Coulomb project repository (bootstrapped from repo-seed template)
 
-**Domain:** vergabe_teilnahme
-**Repo slug:** vergabe_teilnahme
-**Topic ID:** `7d4d3e35-312f-4723-bde9-ddb43799109e`
-**Workplan prefix:** `VERGABE_TEILNAHME-WP-`
+**Domain:** communication
+**Repo slug:** vergabe-teilnahme
+**Topic ID:** `36c7421b-c537-4723-bf75-42a3ebc6a1dc`
+**Workplan prefix:** `WP-`
 
 ---
 
@@ -28,11 +28,11 @@ there is no MCP server for Codex agents.
 cat .custodian-brief.md
 
 # Active workstreams for this domain
-curl -s "http://127.0.0.1:8000/workstreams/?topic_id=7d4d3e35-312f-4723-bde9-ddb43799109e&status=active" \
+curl -s "http://127.0.0.1:8000/workstreams/?topic_id=36c7421b-c537-4723-bf75-42a3ebc6a1dc&status=active" \
   | python3 -m json.tool
 
 # Check inbox
-curl -s "http://127.0.0.1:8000/messages/?to_agent=vergabe_teilnahme&unread_only=true" \
+curl -s "http://127.0.0.1:8000/messages/?to_agent=vergabe-teilnahme&unread_only=true" \
   | python3 -m json.tool
 ```
 
@@ -63,8 +63,8 @@ Omit `workstream_id` / `task_id` when not applicable.
 ```bash
 curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
   -H "Content-Type: application/json" \
-  -d '{"status": "in_progress"}'
-# values: todo | in_progress | done | blocked
+  -d '{"status": "progress"}'
+# values: wait | todo | progress | done | cancel
 ```
 
 ### Flag a task for human review
@@ -81,9 +81,9 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 
 **Start:**
 1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
-2. Check inbox: `GET /messages/?to_agent=vergabe_teilnahme&unread_only=true`; mark read
+2. Check inbox: `GET /messages/?to_agent=vergabe-teilnahme&unread_only=true`; mark read
 3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
-4. Check blocked tasks: `GET /tasks/?needs_human=true`
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
 
 **During work:**
 - Update task statuses in workplan files as tasks progress
@@ -95,21 +95,78 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 3. Note for the custodian operator: after workplan file changes, run from
    `~/state-hub`:
    ```bash
-   make fix-consistency REPO=vergabe_teilnahme
+   make fix-consistency REPO=vergabe-teilnahme
    ```
    This syncs task status from files into the hub DB.
 
 ---
 
+## Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=vergabe-teilnahme` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
+---
+
 ## Workplan Convention (ADR-001)
 
 Work items originate as files in this repo — not in the hub. The hub is a
 read/cache/index layer that rebuilds from files.
 
-**File location:** `workplans/VERGABE_TEILNAHME-WP-NNNN-<slug>.md`
+**File location:** `workplans/VERGABE-WP-NNNN-<slug>.md`
 
 **Archived location:** finished workplans may move to
-`workplans/archived/YYMMDD-VERGABE_TEILNAHME-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+`workplans/archived/YYMMDD-VERGABE-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
 the completion/archive date; the frontmatter `id` does not change.
 
 **Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
@@ -121,11 +178,11 @@ anything needing analysis, design, approval, dependencies, or multiple phases.
 
 ```yaml
 ---
-id: VERGABE_TEILNAHME-WP-NNNN
+id: VERGABE-WP-NNNN
 type: workplan
 title: "..."
-domain: vergabe_teilnahme
-repo: vergabe_teilnahme
+domain: communication
+repo: vergabe-teilnahme
 status: proposed | ready | active | blocked | backlog | finished | archived
 owner: codex
 topic_slug: ...
@@ -145,8 +202,8 @@ derived health labels, not frontmatter statuses.
 ## Task Title
 
 ` ` `task
-id: VERGABE_TEILNAHME-WP-NNNN-T01
-status: todo | in_progress | done | blocked
+id: VERGABE-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
 priority: high | medium | low
 state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 ` ` `
@@ -154,9 +211,9 @@ state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 Task description text.
 ```
 
-Status progression: `todo` → `in_progress` → `done` (or `blocked`)
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
 
 To create a new workplan:
 1. Write the file following the format above
-2. Notify the custodian operator to run `make fix-consistency REPO=vergabe_teilnahme`
+2. Notify the custodian operator to run `make fix-consistency REPO=vergabe-teilnahme`
    (or send a message to the hub agent via `POST /messages/`)

CLAUDE.md

@@ -8,4 +8,5 @@
 @.claude/rules/stack-and-commands.md
 @.claude/rules/architecture.md
 @.claude/rules/repo-boundary.md
+@.claude/rules/credential-routing.md
 @.claude/rules/agents.md

SCOPE.md

@@ -8,130 +8,147 @@
 
 ## One-liner
 
-<!-- Describe the purpose of this repository in one precise sentence. -->
-<!-- Example: "Provides a lightweight event router for Kubernetes-native systems." -->
+Web application that structures a company's participation in tenders
+(Ausschreibungen) end-to-end, from research through submission to
+post-award retrospective.
 
 ---
 
 ## Core Idea
 
-<!-- What is the main capability or idea behind this repository? -->
-<!-- What problem does it try to solve? -->
+**Vergabe Teilnahme** ("tender participation") guides a team through the
+full lifecycle of bidding on a public or private tender: collecting tender
+documents, analyzing requirements, deciding whether to participate, tracking
+open items, finalizing pricing and documents, submitting on time, and
+capturing reusable knowledge afterwards — win or lose. It is phase-guided,
+never phase-locked: every element of a tender is reachable at any time, and
+there is no forced completeness outside real submission-deadline
+constraints. All data entry is manual in this first build stage — no
+automated ingestion from tender platforms.
+
+It operates on three levels, per `wiki/ProductRequirementsDocument.md`:
+
+| Level | Content |
+|---|---|
+| Operational | deadlines, documents, tasks, lots (Lose), requirements, bidder questions, submission |
+| Management | participate/no-bid decision, approvals, pricing level, subcontractor selection, outcome, retrospective |
+| Strategic | reusable evidence/references, market price observation, loss reasons, win factors, competitor (Marktbegleiter) analysis |
 
 ---
 
 ## In Scope
 
-<!-- What this repository is responsible for. -->
-<!-- Be explicit and concrete. -->
-
--
--
--
-
----
+- Tender (Ausschreibung) and lot (Los) tracking through 8 navigable phases
+- Requirements analysis and bidder-question (Bieterfragen) handling
+- Task management (Aufgaben) scoped to a tender or a lot
+- Document management (Dokumente) for tender materials and submission artifacts
+- Pricing (Preise) tracking per lot/tender
+- Submission and post-award retrospective (Abgabe/Nachbetrachtung)
+- Partner and reference library (Partner/Bibliothek) for reusable evidence
+- Competitor/market observation (Marktbegleiter)
+- Feedback/bug capture within the app (Feedback)
+- Issue-tracking integration via `issue-core` (task facade, not a UI replacement)
 
 ## Out of Scope
 
-<!-- What this repository deliberately does NOT do. -->
-<!-- This is often more important than "In Scope". -->
-
--
--
--
+- External user accounts for partners/subcontractors/service providers (data
+  objects only in this build stage, no system access of their own)
+- Multi-tenancy
+- Automated ingestion from tender platforms, SharePoint, Teams, CRM, ERP,
+  email, or calendars (deliberately manual-entry-first for v1)
+- Certification or legal validity of submissions — the system tracks
+  process state, it is not a legal compliance authority
 
 ---
 
 ## Relevant When
 
-<!-- When should someone consider using or exploring this repository? -->
-
--
--
--
-
----
+- Deciding whether to bid on a tender and needing structured deadline,
+  document, and requirement tracking across a team
+- Needing a system of record for pricing decisions, submission evidence,
+  and post-award retrospectives on public/private tenders
+- Wanting to reuse prior tender evidence, references, or competitor/pricing
+  observations when evaluating a new tender
 
 ## Not Relevant When
 
-<!-- When should someone ignore this repository? -->
-
--
--
--
+- Needing external bidder/partner portal access (not built yet)
+- Needing automated tender discovery or platform integration (out of scope
+  for this build stage)
+- Needing generic project management unrelated to the tender-participation
+  domain
 
 ---
 
 ## Current State
 
-<!-- Rough indication of maturity. No strict format required. -->
-
-- Status: <!-- e.g. concept / experimental / active / stable / deprecated -->
-- Implementation: <!-- e.g. idea / partial / substantial / complete -->
-- Stability: <!-- e.g. unstable / evolving / stable -->
-- Usage: <!-- e.g. none / personal / internal / production -->
-
-<!-- Add any notes that help set expectations. -->
+- Status: active
+- Implementation: substantial — 12 Django apps covering the full phase
+  model (accounts, aufgaben, ausschreibungen, bibliothek, core, dokumente,
+  feedback, lose, marktbegleiter, nachbetrachtung, partner, preise); 17
+  workplans (WP-0001–WP-0017) implemented in sequence from project
+  scaffold through whynot-design token adoption
+- Stability: evolving — manual-entry-first v1; no CI workflow configured yet
+  (`.gitea/`/`.forgejo/` absent)
+- Usage: internal collaboration tool, not yet published for external use
 
 ---
 
 ## How It Fits
 
-<!-- Where does this repository sit in the bigger picture? -->
-
-- Upstream dependencies:
-- Downstream consumers:
-- Often used with:
+- Upstream dependencies: `issue-core` (task-tracking facade, see
+  `vergabe_teilnahme/apps/aufgaben/issue_facade.py`), `whynot-design`
+  (visual language, vendored CSS/tokens)
+- Downstream consumers: none known
+- Often used with: `railiance-apps` (deployment target per its own SCOPE.md,
+  which names `vergabe-teilnahme` as a user-facing service it deploys)
 
 ---
 
 ## Terminology
 
-<!-- Terms that are important to understand this repo. -->
-<!-- Especially useful if naming differs from other repos. -->
-
-- Preferred terms:
-- Also known as:
-- Potentially confusing terms:
+- Preferred terms: Ausschreibung (tender), Los (lot), Aufgabe (task),
+  Marktbegleiter (competitor/market companion), Nachbetrachtung (post-award
+  retrospective)
+- Also known as: "Vergabe Teilnahme" (product name), "tender participation
+  management system" (English gloss)
+- Potentially confusing terms: "Partner" here means reference/subcontractor
+  data objects, not system users
 
 ---
 
 ## Related / Overlapping Repositories
 
-<!-- List repositories that have similar or adjacent responsibilities. -->
-<!-- Helps detect duplication and navigate the ecosystem. -->
-
-- <repo-name> — <!-- how it relates -->
+- `issue-core` — task-tracking backend consumed via `issue_facade.py`
+- `whynot-design` — visual language vendored into `static/src/vendor/`
+- `railiance-apps` — deployment/workload layer for this service
 
 ---
 
 ## Getting Oriented
 
-<!-- If someone decides to look deeper, where should they start? -->
-
-- Start with:
-- Key files / directories:
-- Entry points:
+- Start with: `wiki/ProductRequirementsDocument.md` (product intent, in
+  German), `wiki/ArchitectureBlueprint.md` (technology stack and design
+  principles)
+- Key files / directories: `vergabe_teilnahme/apps/` (12 domain apps),
+  `vergabe_teilnahme/urls.py` (route map), `workplans/` (WP-0001–0017
+  build history)
+- Entry points: `manage.py runserver`; `vergabe_teilnahme/urls.py` maps
+  `/ausschreibungen/`, `/lose/`, `/aufgaben/`, `/dokumente/`, and more
 
 ---
 
 ## Provided Capabilities
 
-<!-- What can this repo's domain provide to other domains on request? -->
-<!-- Each capability block is parsed by the state-hub capability catalog ingest. -->
-<!-- Remove the examples and add your own, or leave empty if none. -->
-
-<!--
-```capability
-type: infrastructure
-title: Example capability title
-description: What this capability provides, in one or two sentences.
-keywords: [keyword1, keyword2, keyword3]
-```
--->
+Registered in `registry/capabilities/capability.procurement.vergabe-teilnahme.md`
+(reuse-surface federation; vector **D3/A1/C1/R1** after SCOPE.md fill-in and
+REUSE-WP-0017-T05 entry-2 review, 2026-07-07).
 
 ---
 
 ## Notes
 
-<!-- Anything else worth knowing. Keep it short. -->
+Product and architecture documentation (`wiki/`) is in German; this SCOPE.md
+is in English per the reuse-surface registry's Markdown-first, agent-facing
+convention. Refer to `wiki/ProductRequirementsDocument.md` for the
+authoritative German-language product definition.

registry/README.md

@@ -0,0 +1,12 @@
+# Capability Registry
+
+Markdown-first capability index for federation and reuse planning.
+
+## Authoring
+
+1. Copy a capability entry template (see reuse-surface `templates/capability-entry.template.md`).
+2. Add the row to `indexes/capabilities.yaml`.
+3. Run `reuse-surface validate` from a checkout with the CLI installed.
+4. Merge to `main` and verify publish with `reuse-surface establish --publish-check`.
+
+Federation contract: reuse-surface `docs/RegistryFederation.md`.

registry/capabilities/capability.procurement.vergabe-teilnahme.md

@@ -0,0 +1,147 @@
+---
+id: capability.procurement.vergabe-teilnahme
+name: Vergabe Teilnahme (Public Procurement Participation) Application
+summary: Django application (with a Vite/Tailwind frontend) for managing German public-procurement (Vergabe)
+  tender participation — Ausschreibungs- und Teilnahme-Management-System.
+owner: vergabe-teilnahme
+status: draft
+domain: communication
+tags:
+- procurement
+- django
+- vergabe
+maturity:
+  discovery:
+    current: D3
+    target: D4
+    confidence: medium
+    rationale: SCOPE.md filled 2026-07-07 with in/out scope, current state, terminology, and orientation
+      pointers; supported by wiki/ProductRequirementsDocument.md (German product definition) and
+      wiki/ArchitectureBlueprint.md. README.md remains a stale repo-seed leftover — SCOPE and wiki
+      are authoritative for discovery.
+  availability:
+    current: A1
+    target: A3
+    confidence: medium
+    rationale: Substantial Django application (12 domain apps, WP-0001–WP-0017 implemented) with
+      Vite/Tailwind frontend and docker-compose dev/test; SCOPE.md describes internal collaboration
+      use only — no hosted production deployment confirmed in this review.
+external_evidence:
+  completeness:
+    level: C1
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+    - in-scope/out-of-scope boundaries documented in SCOPE.md
+    - 8-phase tender participation model described with operational/management/strategic levels
+    - manual-entry-first v1 constraint and external-portal exclusion explicit
+    broken_expectations: []
+    out_of_scope_expectations: []
+  reliability:
+    level: R1
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+    - no CI workflow configured yet (per SCOPE.md current state)
+    - no production consumer telemetry (REUSE-WP-0019)
+    - README.md still stale repo-seed text — fix separately
+discovery:
+  intent: Guide a team through the full lifecycle of bidding on public or private tenders (Ausschreibungen)
+    — from research and participate/no-bid decisions through submission and post-award retrospective.
+  includes:
+  - tender (Ausschreibung) and lot (Los) tracking across 8 navigable phases
+  - requirements analysis and bidder-question (Bieterfragen) handling
+  - tasks (Aufgaben), documents (Dokumente), pricing (Preise), submission/retrospective (Abgabe/Nachbetrachtung)
+  - partner/reference library (Bibliothek) and competitor observation (Marktbegleiter)
+  - issue-core task facade integration (not a UI replacement)
+  excludes:
+  - external partner/subcontractor portal accounts (data objects only in v1)
+  - multi-tenancy
+  - automated ingestion from tender platforms, SharePoint, Teams, CRM, ERP, email, or calendars
+  assumptions: []
+  use_cases: []
+  research_memos: []
+availability:
+  current_level: A1
+  target_level: A3
+  current_artifacts:
+  - Django application (`vergabe_teilnahme`, 12 apps)
+  - Vite/Tailwind frontend (`static/`)
+  - docker-compose.dev.yml and docker-compose.test.yml
+  target_artifacts: []
+  consumption_modes:
+  - application (Django + Vite, local dev via docker-compose)
+relations:
+  depends_on:
+  - capability.infotech.issue-tracking
+  supports: []
+  related_to:
+  - capability.design.whynot-system
+evidence:
+  documentation:
+  - SCOPE.md
+  - wiki/ProductRequirementsDocument.md
+  - wiki/ArchitectureBlueprint.md
+  - pyproject.toml
+  tests:
+  - vergabe_teilnahme/apps/*/tests.py (pytest-django suite across domain apps)
+  - docker-compose.test.yml
+  consumer_feedback: []
+  bug_reports: []
+  incidents: []
+consumer_guidance:
+  recommended_for:
+  - teams needing structured German tender-participation workflow tracking (manual-entry-first v1)
+  - extending or deploying this specific Django application
+  not_recommended_for:
+  - automated tender-platform ingestion (out of scope for v1)
+  - external bidder/partner self-service portals (not built)
+  known_limitations:
+  - manual data entry only in v1 — no platform integration
+  - README.md is still repo-seed boilerplate; use SCOPE.md and wiki/ for orientation
+promotion_history:
+- date: "2026-07-07"
+  dimension: discovery
+  from: D1
+  to: D3
+  rationale: SCOPE.md filled with full in/out scope and current-state documentation (REUSE-WP-0017-T05 entry-2 review).
+  author: grok
+- date: "2026-07-07"
+  dimension: completeness
+  from: C0
+  to: C1
+  rationale: Consumer scope expectations now documented in SCOPE.md and wiki PRD.
+  author: grok
+---
+
+# Vergabe Teilnahme (Public Procurement Participation) Application
+
+## Overview
+
+`vergabe-teilnahme` is a Django + Vite/Tailwind application for managing German public-procurement (Vergabe) tender participation end-to-end. SCOPE.md (filled 2026-07-07) documents the 8-phase, manual-entry-first v1 model across 12 Django apps.
+
+## Assessment notes
+
+### Discovery
+
+SCOPE.md now provides authoritative in/out scope, current state, terminology, and pointers to the German-language wiki PRD and architecture blueprint. Discovery promoted from D1 to D3; README cleanup remains a separate hygiene item.
+
+### Availability
+
+Substantial implemented application (WP-0001–WP-0017) with local docker-compose paths. Held at A1 until a hosted deployment path is confirmed (railiance-apps is named as deployment target in SCOPE.md).
+
+### Completeness
+
+Scope-vs-intent expectations are now documented (C1). Feature completeness against the full PRD is not independently verified in this review.
+
+### Reliability
+
+Pytest-django suite exists across domain apps (structural R1). No CI workflow or production telemetry yet.
+
+## Promotion checklist
+
+- [x] ID follows `capability.<domain>.<name>` pattern
+- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
+- [x] `external_evidence` is populated separately from `maturity`
+- [x] Relations reference valid capability IDs
+- [x] Index entry added in `registry/indexes/capabilities.yaml`

registry/indexes/capabilities.yaml

@@ -0,0 +1,19 @@
+version: 1
+updated: '2026-07-07'
+domain: helix_forge
+capabilities:
+- id: capability.procurement.vergabe-teilnahme
+  name: Vergabe Teilnahme (Public Procurement Participation) Application
+  summary: Django application (with a Vite/Tailwind frontend) for managing German public-procurement (Vergabe)
+    tender participation — Ausschreibungs- und Teilnahme-Management-System.
+  vector: D3 / A1 / C1 / R1
+  domain: communication
+  status: draft
+  owner: vergabe-teilnahme
+  path: registry/capabilities/capability.procurement.vergabe-teilnahme.md
+  tags:
+  - procurement
+  - django
+  - vergabe
+  consumption_modes:
+  - application (Django + Vite, local dev via docker-compose)

uv.lock

@@ -362,38 +362,15 @@ wheels = [
 [[package]]
 name = "issue-core"
 version = "0.2.0"
-source = { directory = "../issue-core" }
+source = { registry = "https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/" }
 dependencies = [
     { name = "click" },
     { name = "python-dateutil" },
     { name = "requests" },
 ]
-
-[package.metadata]
-requires-dist = [
-    { name = "black", marker = "extra == 'dev'", specifier = ">=22.0" },
-    { name = "click", specifier = ">=8.0.0" },
-    { name = "fastapi", marker = "extra == 'api'", specifier = ">=0.110,<1.0" },
-    { name = "fastapi", marker = "extra == 'dev'", specifier = ">=0.110,<1.0" },
-    { name = "flake8", marker = "extra == 'dev'", specifier = ">=4.0" },
-    { name = "httpx", marker = "extra == 'dev'", specifier = ">=0.27" },
-    { name = "isort", marker = "extra == 'dev'", specifier = ">=5.0" },
-    { name = "jira", marker = "extra == 'jira'", specifier = ">=3.0" },
-    { name = "mypy", marker = "extra == 'dev'", specifier = ">=0.900" },
-    { name = "pre-commit", marker = "extra == 'dev'", specifier = ">=2.0" },
-    { name = "pydantic", marker = "extra == 'api'", specifier = ">=2.0,<3.0" },
-    { name = "pydantic", marker = "extra == 'dev'", specifier = ">=2.0,<3.0" },
-    { name = "pygithub", marker = "extra == 'github'", specifier = ">=1.55" },
-    { name = "pytest", marker = "extra == 'dev'", specifier = ">=6.0" },
-    { name = "pytest-cov", marker = "extra == 'dev'", specifier = ">=2.0" },
-    { name = "pytest-mock", marker = "extra == 'dev'", specifier = ">=3.0" },
-    { name = "python-dateutil", specifier = ">=2.8.0" },
-    { name = "requests", specifier = ">=2.25.0" },
-    { name = "requests", marker = "extra == 'gitea'", specifier = ">=2.25.0" },
-    { name = "sphinx", marker = "extra == 'docs'", specifier = ">=4.0" },
-    { name = "sphinx-click", marker = "extra == 'docs'", specifier = ">=3.0" },
-    { name = "sphinx-rtd-theme", marker = "extra == 'docs'", specifier = ">=1.0" },
-    { name = "uvicorn", extras = ["standard"], marker = "extra == 'api'", specifier = ">=0.27,<1.0" },
+sdist = { url = "http://gitea.coulomb.social/api/packages/coulomb/pypi/files/issue-core/0.2.0/issue_core-0.2.0.tar.gz", hash = "sha256:cd456ccafdf540f02f7f8b1326e28f8acebcfa0476f3ea2245bd2a5230d85a8d" }
+wheels = [
+    { url = "http://gitea.coulomb.social/api/packages/coulomb/pypi/files/issue-core/0.2.0/issue_core-0.2.0-py3-none-any.whl", hash = "sha256:f98b90a13c787095834dbc7ff8b14057718884e01a51c6b13206e438ba1d5f90" },
 ]
 
 [[package]]
@@ -791,7 +768,7 @@ requires-dist = [
     { name = "django", specifier = ">=5.2" },
     { name = "django-storages", specifier = ">=1.14" },
     { name = "gunicorn", specifier = ">=22.0" },
-    { name = "issue-core", directory = "../issue-core" },
+    { name = "issue-core", specifier = ">=0.2,<0.3", index = "https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/" },
     { name = "psycopg", extras = ["binary"], specifier = ">=3.2" },
     { name = "python-decouple", specifier = ">=3.8" },
     { name = "whitenoise", specifier = ">=6.7" },

workplans/WP-0001-projektgeruest.md

@@ -4,6 +4,7 @@ title: Projektgerüst — Django-Setup, Tailwind, Dev-Stack
 status: done
 phase: 1-of-12
 created: "2026-05-08"
+domain: communication
 ---
 
 # WP-0001 — Projektgerüst

workplans/WP-0002-fachmodelle.md

@@ -5,6 +5,7 @@ status: done
 phase: 2-of-12
 created: "2026-05-08"
 depends_on: WP-0001
+domain: communication
 ---
 
 # WP-0002 — Fachmodelle

workplans/WP-0003-basis-ui.md

@@ -5,6 +5,7 @@ status: done
 phase: 3-of-12
 created: "2026-05-08"
 depends_on: WP-0002
+domain: communication
 ---
 
 # WP-0003 — Basis-UI

workplans/WP-0004-dashboard-ausschreibungen.md

@@ -5,6 +5,7 @@ status: done
 phase: 4-of-12
 created: "2026-05-08"
 depends_on: WP-0003
+domain: communication
 ---
 
 # WP-0004 — Dashboard und Ausschreibungen-CRUD

workplans/WP-0005-lose-anforderungen.md

@@ -5,6 +5,7 @@ status: done
 phase: 5-of-12
 created: "2026-05-08"
 depends_on: WP-0004
+domain: communication
 ---
 
 # WP-0005 — Lose und Anforderungen

workplans/WP-0006-aufgaben-bieterfragen.md

@@ -5,6 +5,7 @@ status: done
 phase: 6-of-12
 created: "2026-05-08"
 depends_on: WP-0005
+domain: communication
 ---
 
 # WP-0006 — Aufgaben und Bieterfragen

workplans/WP-0007-dokumente.md

@@ -5,6 +5,7 @@ status: done
 phase: 7-of-12
 created: "2026-05-08"
 depends_on: WP-0006
+domain: communication
 ---
 
 # WP-0007 — Dokumentenmanagement

workplans/WP-0008-preise.md

@@ -5,6 +5,7 @@ status: done
 phase: 8-of-12
 created: "2026-05-08"
 depends_on: WP-0007
+domain: communication
 ---
 
 # WP-0008 — Preise und Marktpreisauswertung

workplans/WP-0009-abgabe-nachbetrachtung.md

@@ -5,6 +5,7 @@ status: done
 phase: 9-of-12
 created: "2026-05-08"
 depends_on: WP-0008
+domain: communication
 ---
 
 # WP-0009 — Abgabe (Phase 6/7) und Nachbetrachtung (Phase 8)

workplans/WP-0010-partner-bibliothek.md

@@ -5,6 +5,7 @@ status: done
 phase: 10-of-12
 created: "2026-05-08"
 depends_on: WP-0009
+domain: communication
 ---
 
 # WP-0010 — Subunternehmer, Partner und Bibliothek

workplans/WP-0011-marktbegleiter.md

@@ -5,6 +5,7 @@ status: done
 phase: 11-of-12
 created: "2026-05-08"
 depends_on: WP-0010
+domain: communication
 ---
 
 # WP-0011 — Marktbegleiter-Analyse

workplans/WP-0012-querschnitt.md

@@ -5,6 +5,7 @@ status: done
 phase: 12-of-12
 created: "2026-05-08"
 depends_on: WP-0011
+domain: communication
 ---
 
 # WP-0012 — Querschnitt

workplans/WP-0013-feedback-bugs.md

@@ -5,6 +5,7 @@ status: done
 phase: 13-of-13
 created: "2026-05-14"
 depends_on: WP-0012
+domain: communication
 ---
 
 # WP-0013 — Feedback-Bugs

workplans/WP-0014-aufgaben-lose-scores.md

@@ -5,6 +5,7 @@ status: done
 phase: 14-of-n
 created: "2026-05-14"
 depends_on: WP-0013
+domain: communication
 ---
 
 # WP-0014 — Aufgaben-Phasenzuordnung und Scores

workplans/WP-0015-aufgaben-verknuepfungen-frist-issuefacade.md

@@ -5,6 +5,7 @@ status: done
 phase: 15-of-n
 created: "2026-05-14"
 depends_on: WP-0014
+domain: communication
 ---
 
 # WP-0015 — Aufgaben: Verknüpfungen, implizite Fälligkeit, Issue-Facade

workplans/WP-0016-issue-facade-integration.md

@@ -5,6 +5,7 @@ status: done
 phase: 16-of-n
 created: "2026-05-14"
 depends_on: WP-0015
+domain: communication
 ---
 
 # WP-0016 — Issue-Facade Integration

workplans/WP-0017-whynot-design-tokens.md

@@ -5,6 +5,7 @@ status: finished
 phase: 17-of-n
 created: "2026-05-23"
 depends_on: WP-0016
+domain: communication
 ---
 
 # WP-0017 — whynot-design Adoption · Phase 1 (Tokens + CSS)