feat: Enhance architecture and roadmap documentation with material extensibility and persistence layer details

docs/OPEN_QUESTIONS.md

@@ -13,6 +13,9 @@ Each question is tagged with the phase it blocks or most affects: [P0], [P1], [P
 - Explicit project versioning is preferred and should be supported.
 - A project is composable: FeDIY provides a minimal core model, and instances can tailor project detail via optional domain-specific extensions.
 - FeDIY should not require first-party implementation of every domain detail up front; expert communities can define richer schemas over time.
+- Materials are also extensible entities. The core material record (name, quantity, unit) can carry domain-specific extension payloads using the same mechanism as project extensions. Community-defined material type schemas (e.g. yarn, filament, PCB component) can be layered on without modifying the core model.
+- **Database: PostgreSQL is the primary persistence target.** JSONB, native full-text search, transactional consistency under concurrent federation fan-in, and broad managed hosting support make it the clear long-term fit. The persistence layer is behind a repository abstraction (trait-based interfaces), which keeps business logic independent of the database driver and leaves SQLite viable as a future lightweight self-hosting option without requiring changes to domain logic. See [ADR TBD: Persistence Layer Architecture].
+- **Baseline content prohibitions (hardcoded, not operator-configurable):** CSAM, doxxing, and non-consensual intimate imagery (NCII) are prohibited on any FeDIY instance regardless of operator policy. The guiding principle is **consent**: minors cannot consent to sexual content; individuals have not consented to having their private identifying information published; subjects of intimate imagery have not consented to its distribution. Enforcement is in-code as far as technically feasible (hash-matching for CSAM and NCII; upload-time pattern detection and mandatory human-review tooling for doxxing). Weapons, violence, and similar dual-use content are **not** hardcoded prohibitions — legitimate DIY projects (fireworks, blacksmithing, knife-making) are indistinguishable at the software level and are handled by operator content policy and community moderation.
 
 ## Upfront Clarification Plan (P0 -> Early P1)
 
@@ -26,9 +29,9 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 
 1. Decision track B: Core-plus-extension contract
 
-- Resolve Q2, Q2a, Q2b, and Q2c as one coherent contract.
-- Output: one ADR for core project fields and one ADR for extension payload shape/namespacing/discovery.
-- Success signal: instances can add domain-specific detail (knitting, 3D print, electronics, etc.) without changing core semantics.
+- Resolve Q2, Q2a, Q2b, Q2c, and Q2d as one coherent contract.
+- Output: one ADR for core project and material fields, and one ADR for extension payload shape/namespacing/discovery (shared by both project and material extensions).
+- Success signal: instances can add domain-specific detail at both the project level and the material entry level (knitting yarn specs, 3D filament profiles, electronics BoM entries, etc.) without changing core semantics.
 
 1. Decision track C: Search/index policy for extensions
 
@@ -57,6 +60,26 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 
 - Free-text only, or linked to a shared taxonomy/catalog?
 - Do quantities and units need to be structured (for search/filtering), or is prose sufficient for MVP?
+- Are materials solely inline entries within a project, or are they also independent top-level entities that can be referenced by multiple projects?
+- Does the core material record have a fixed set of fields (name, quantity, unit, optional note) with extension payloads carrying domain-specific attributes? Or is the entire material record opaque beyond a display name?
+- How are domain-specific material extensions (yarn weight/fibre/colourway, filament diameter/material/temperature profile, wood species/grade/finish, electronics component value/tolerance/package) represented? Same extension payload shape as project extensions, or a separate material-type schema?
+- At what phase should structured quantity/unit data be required? A unit normalisation scheme (SI base + common craft units) would enable cross-instance filtering and quantity scaling; is that P1 or later?
+
+**Q2d [P1/P2]** What is the extension model for domain-specific material data?
+
+- Does a material entry carry the same extension payload mechanism as a project (namespaced typed block, discoverable schema)?
+- Who can define a material type schema — instance operators only, or any community contributor who publishes a schema at a well-known URL?
+- Should FeDIY ship a small set of reference material type schemas (yarn, 3D filament, electronic component) as non-mandatory examples to establish the pattern?
+- How does a client know which material type extension(s) a given entry carries, and how does it fall back gracefully when it does not support the type?
+- What is the relationship between project-level extensions and material-level extensions? Can a domain extension define both a project schema and a material schema that are versioned together?
+
+**Q2e [P2/P3]** What would a federated material catalog look like?
+
+- Could shared material types (e.g. a yarn colourway catalog, a filament brand/profile registry) be published as ActivityPub objects and federated between instances?
+- What ActivityPub object type would a material catalog entry use? A custom `fediy:MaterialType` in a FeDIY JSON-LD context, or an existing vocabulary term?
+- Who is authoritative for a shared catalog entry — the originating instance, a designated community instance, or a multi-instance governance process?
+- How does a material catalog entry interact with the right to erasure / RTBF? If a community-curated entry (not personal data) is federated, different deletion semantics apply than for user personal data.
+- Is a federated catalog in scope before federation is live (Phase 2), or does it only make sense alongside AP federation?
 
 **Q2a [P1]** How are required tools modelled?
 
@@ -256,10 +279,9 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 
 ## Persistence
 
-**Q27 [P0/P1]** What is the database?
+**Q27 [P0/P1]** ~~What is the database?~~ **RESOLVED — see Resolved Decisions.**
 
-- PostgreSQL is the obvious choice given full-text search, JSONB for flexible AP object storage, and broad hosting support — is this confirmed?
-- Is SQLite a supported option for lightweight self-hosting, or is that complexity not worth it?
+Decision: PostgreSQL as primary target with a repository abstraction layer. SQLite is a possible future option (hobbyist self-hosting) enabled by the abstraction without changing business logic. Decision track: one ADR to cover the persistence layer architecture (database choice + repository pattern + query library selection).
 
 **Q28 [P1]** What is the database migration strategy?
 
@@ -336,10 +358,9 @@ The goal is to remove ambiguity before implementation while keeping scope realis
 
 ## Content and Community Policy
 
-**Q36 [P0]** Does the platform define baseline content guidelines beyond what moderation tooling enforces?
+**Q36 [P0]** ~~Does the platform define baseline content guidelines beyond what moderation tooling enforces?~~ **RESOLVED — see Resolved Decisions.**
 
-- What categories of content are prohibited regardless of instance policy?
-- CSAM must be prohibited and reported — is there a mechanism planned?
+Decision: CSAM, doxxing, and NCII are hardcoded prohibitions enforced in code as far as technically feasible. The guiding principle is consent. Weapons and dual-use DIY content are not hardcoded — handled by operator policy.
 
 **Q37 [P4]** Are collaborative/co-authorship workflows in scope?