generated from coulomb/repo-seed
Fill in SCOPE.md (was an unfilled template)
Written from direct inspection of the 12-app Django domain model, wiki/ProductRequirementsDocument.md, and wiki/ArchitectureBlueprint.md. Requested during reuse-surface REUSE-WP-0017-T05 review follow-up. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
159
SCOPE.md
159
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, D1/A1/C0/R0 as of the initial coverage sweep —
|
||||
low discovery confidence pending this SCOPE.md's first real fill-in).
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
Reference in New Issue
Block a user