How tomfromtomsk/rhiori works
Purpose and Scope
This repository currently contains product-definition material rather than an implemented application. The primary artifact is PRD.md; supporting external-reference notes live under references/.
Entry Points
There are no executable entry points, services, packages, or runtime manifests in the supplied tree. Work should begin from the requirements in PRD.md.
Product Requirements Boundary
PRD.md is the authoritative source for intended behavior, user flows, domain rules, and acceptance criteria. It should drive subsequent implementation decomposition and architecture decisions.
Reference Material
The references/paprika/ subtree isolates notes related to Paprika rather than mixing them into the core product document:
• references/paprika/paprika_url.md
This indicates Paprika URLs may be an external integration, import/export format, deep-link target, or compatibility constraint; its exact role must be established from the referenced document before designing that boundary.
Intended Architecture Stages
No concrete source modules exist yet. A future implementation will likely need to separate:
1. Requirement-derived application/domain behavior from PRD.md.
2. Paprika-specific URL parsing, generation, or integration logic based on references/paprika/paprika_url.md.
3. Any application interface, persistence, API, or deployment layers implied by the PRD.
Data and Control Flow
The only visible flow is documentation-driven: product requirements in PRD.md define the system, while Paprika URL semantics in references/paprika/paprika_url.md constrain an external-format boundary. No implemented data stores, APIs, queues, authentication systems, cloud infrastructure, or third-party SDKs are present.
Current Architectural Constraints
Treat the repository as pre-implementation. Do not infer a web, mobile, CLI, or backend runtime from the tree alone. Before adding code, extract explicit actors, entities, workflows, integration direction, and nonfunctional requirements from PRD.md, then define an adapter boundary around Paprika URL behavior.
Main entry points: PRD.md Product requirements · paprika_url.md Paprika URL notes
Components 6
Product Definition
Authoritative inputs for implementation planning.
- Product requirements · Defines intended behavior, flows, rules, and acceptance criteria.
PRD.md
External Format Boundary
Paprika-specific compatibility material.
- Paprika URL notes · Defines URL semantics that must be clarified before integration design.
references/paprika/paprika_url.md - Paprika URL adapter · Parsing, generation, or compatibility logic determined from the reference notes.
Future Implementation
Architecture to be derived before code is added.
- Requirements analysis · Extract actors, entities, workflows, integrations, and nonfunctional requirements.
- Domain behavior · Requirement-derived product rules and workflows.
- Application layers · Interface, API, persistence, and deployment choices only where required by the PRD.
Connections 7
- Product requirements → Requirements analysis: drives
- Requirements analysis → Domain behavior: defines
- Requirements analysis → Application layers: informs
- Paprika URL notes → Paprika URL adapter: constrains
- Requirements analysis → Paprika URL adapter: establishes role
- Domain behavior → Paprika URL adapter: uses when required
- Domain behavior → Application layers: implemented by