tegwick
498b7aa9a5
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.
5.7 KiB
SCOPE
This file helps you quickly understand what this repository is about, when it is relevant, and when it is not. It is intentionally lightweight and may be incomplete.
One-liner
Web application that structures a company's participation in tenders (Ausschreibungen) end-to-end, from research through submission to post-award retrospective.
Core Idea
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
- 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
- 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
- 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
- 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
- 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
- Upstream dependencies:
issue-core(task-tracking facade, seevergabe_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 namesvergabe-teilnahmeas a user-facing service it deploys)
Terminology
- 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
issue-core— task-tracking backend consumed viaissue_facade.pywhynot-design— visual language vendored intostatic/src/vendor/railiance-apps— deployment/workload layer for this service
Getting Oriented
- 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.pymaps/ausschreibungen/,/lose/,/aufgaben/,/dokumente/, and more
Provided Capabilities
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
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.