29 lines
1.1 KiB
Markdown
29 lines
1.1 KiB
Markdown
|
# Open Questions
|
||
|
|
|
||
|
|
## Core ontology
|
||
|
|
|
||
|
|
- Is `Authority → Projection → Affordance` a better primary axis than traditional "state management" terminology?
|
||
|
|
- Should `Mutation` represent intent, transport, state transition, or be split?
|
||
|
|
- Is `Reconciliation` independent enough to be a first-class responsibility?
|
||
|
|
- Should `Communication Window` become a canonical dimension?
|
||
|
|
|
||
|
|
## Pattern language
|
||
|
|
|
||
|
|
- What qualifies as a pattern rather than a technique?
|
||
|
|
- How much implementation detail belongs in canonical patterns?
|
||
|
|
- How do we represent patterns that only make sense at one scale?
|
||
|
|
- How should pattern relations be validated?
|
||
|
|
|
||
|
|
## Agentic use
|
||
|
|
|
||
|
|
- Which metadata is necessary for useful pattern retrieval?
|
||
|
|
- Should the pattern graph be exported as JSON/YAML/RDF?
|
||
|
|
- Can force matching be made quantitative without creating false precision?
|
||
|
|
- Can architecture review be expressed as unresolved-force detection?
|
||
|
|
|
||
|
|
## Evidence
|
||
|
|
|
||
|
|
- What makes a frontend pattern "established"?
|
||
|
|
- Should known uses be manually curated or automatically mined?
|
||
|
|
- How should contradictory source claims be represented?
|