dreamlab-ai Renaissance Architecture
Build genuinely new things. Not "X but for Y."
Core Philosophy
The problem isn't modern tools. It's building commentaries instead of creations.
Medieval scholars wrote commentaries on Aristotle instead of new philosophy. We build Star Wars spin-offs instead of new sci-fi. We add AI to existing workflows instead of asking what workflows become possible.
Renaissance architecture means:
- First-principles thinking about WHAT to build
- Pragmatic choices about HOW to build it
- Creating new paradigms, not extending old ones
- Using modern tools to make genuinely new things possible
The Core Question
When designing anything, ask:
"Am I creating something new, or commenting on something that exists?"
It isn't about rejecting modern tools — it's about using them to build genuinely new things, not just another variation on established patterns. Medieval scholars could only write commentaries because they believed truth was revealed in the past. We have no such limitation. We can create.
Quick-path
- What genuinely new thing are we creating? If the answer is "X but for Y", pause and ask whether Y actually needs X.
- Start with the simplest architecture that could work. Add complexity only when pain is measurable, not theoretical.
- Do the tools serve the creation, or does the creation serve the tools? Frameworks/cloud/microservices earn their place; they aren't defaults.
- Is it human-legible and recoverable? Config a newcomer can read in 10 minutes; errors that teach; undo at the data layer.
- When you deviate from a default, write down why — one sentence in a comment, ADR, or README.
Quick-reference defaults:
| Dimension | Default | Upgrade When |
|---|---|---|
| Storage | SQLite | Concurrent writes, scale, features |
| Framework | Yes, if team knows it | Build from scratch if simpler |
| Cloud | Where genuinely needed | Don't assume, validate |
| Config | YAML/JSON, well-documented | - |
| Errors | Teaching messages | - |
| Loading | Spinners with honest progress | - |
| State | Visible, inspectable | - |
| Undo | Data-layer versioning | - |
| Complexity | Earned, not assumed | Document reasoning |
When to use this skill
Reach for it when designing features, architecting software, brainstorming apps, choosing a stack, reviewing designs, or in strategy discussions — any moment where you're deciding what to build and how much machinery it deserves.
When NOT to use this skill
- Routine bug fixes — there's no "what to build" question, just a defect to correct
- Small, well-scoped feature additions that fit the existing architecture without a stack or paradigm decision
- Work already governed by an existing ADR or architecture doc — follow that record rather than re-litigating it here
- Owning the actual system design for a codebase — that belongs to
architecture-studio; this skill is the philosophy check applied before or alongside that work, not a replacement for it
Detailed guidance (on-demand references)
Load these when the decision at hand needs the full tables and rationale:
- references/architecture.md — the five architecture principles (simplicity, framework choices, human-legible systems, local-first, composition), cloud & infrastructure fit tables, threshold triggers, and justified exceptions.
- references/ui-ux.md — UI/UX philosophy: immediate feedback, visible state, spatial consistency, undo & recovery, respecting attention.
- references/anti-patterns.md — what this rejects (derivative thinking, cargo-cult engineering, premature complexity, process-over-thinking) plus the design-review and solution-generation checklists.
Anti-Dogma Clause
These are defaults, not laws. Violate with documented reasoning. Every principle here has valid exceptions — the goal isn't purity, it's intentionality. Premature complexity is technical debt with interest.
Valid reasons to deviate: team expertise strongly favours a different approach · business timeline requires a faster path · regulatory/compliance requirements · measured performance needs · user research contradicts an assumption.
Invalid reasons to deviate: "everyone does it this way" · "we might need it someday" · "the tutorial used this" · "it's best practice" (without understanding why).
When you deviate, write down why.