103 lines
5.8 KiB
YAML
103 lines
5.8 KiB
YAML
decisions_log:
|
||
- question: >
|
||
Is a dedicated backend_architecture section needed (per the "e.g." placeholder
|
||
comment above)?
|
||
decision: >
|
||
No — a separate backend_architecture section is not needed. Backend detail is
|
||
already captured across the domain-specific sections (media_manager_architecture,
|
||
plugins_architecture, themes_architecture, auth_requirements), which together
|
||
provide sufficient depth on the backend.
|
||
rationale: >
|
||
Those sections already document the relevant backend concerns for their domain
|
||
(storage abstraction, migrations, Service Providers, permissions, etc.), so a
|
||
separate umbrella backend_architecture section would just duplicate them.
|
||
- question: >
|
||
Is a dedicated frontend_architecture section still needed to document how Vue
|
||
Components are organized/bundled, and how they integrate with Fomantic UI and
|
||
the templating engine?
|
||
decision: >
|
||
Yes — a `frontend_architecture` section has been added (see below), filled in
|
||
with what could be gathered from the rest of this document, with its own
|
||
`open_questions` for what couldn't be inferred.
|
||
rationale: >
|
||
Frontend integration (Vue Components + Fomantic UI + Laravel Blade templates) is enough of its own concern to warrant a dedicated section rather than
|
||
being folded into `architecture` or `ui`.
|
||
- question: >
|
||
Given the previous "Multi-tenancy ready" note, should v1's schema/routing
|
||
already carry a tenant identifier (even if unused), or should multi-tenancy be
|
||
deferred entirely to a future major version with its own migration path?
|
||
decision: >
|
||
Multi-tenancy has been removed from consideration altogether — not deferred,
|
||
not kept "ready for" — SiteWeaverCMS is a single-site, single-tenant CMS with
|
||
no planned migration path toward multi-tenancy. The "Multi-tenancy ready" note
|
||
has been removed from `notes` above, and the "Multi-tenancy" glossary term has
|
||
been removed.
|
||
rationale: >
|
||
Avoids carrying unused tenant-identifier columns/routing complexity for a
|
||
direction the project will not pursue.
|
||
- question: How will plugin and theme loading be handled?
|
||
decision: >
|
||
Plugins and themes will be loaded through service providers that register their
|
||
respective services. The plugin manager and theme manager will handle the
|
||
discovery, loading, and unloading of these components at runtime.
|
||
rationale: >
|
||
Using service providers ensures proper dependency injection for plugins and
|
||
themes, while also allowing for lazy loading and easy testing of individual
|
||
components.
|
||
- question: What approach will be used for routing?
|
||
decision: >
|
||
Laravel's routing system will handle all application and plugin routes. Plugins
|
||
can define their own route files or use Route::group to register routes, leveraging
|
||
middleware, named routes, and resource controllers provided by the framework.
|
||
rationale: >
|
||
Using Laravel’s built-in router provides a well-tested, feature-rich routing
|
||
layer that supports middleware, route caching, and easy integration with
|
||
authentication guards and API resources.
|
||
- question: How will configuration be managed?
|
||
decision: >
|
||
Configuration will be handled through a service that loads from environment
|
||
variables and .env files (if available), with support for runtime updates.
|
||
rationale: >
|
||
Using environment variables for configuration ensures secure handling of
|
||
sensitive data while allowing for easy deployment to different environments.
|
||
- question: How will services be registered?
|
||
decision: >
|
||
Services will be registered using Laravel’s service provider pattern. Core
|
||
services go into core service providers, application-level services in
|
||
AppServiceProvider, and plugin/theme-specific services into their own
|
||
service providers.
|
||
rationale: >
|
||
This follows Laravel conventions, enabling lazy loading, caching of
|
||
bindings, and integration with the framework's lifecycle events.
|
||
- question: How will caching be implemented?
|
||
decision: >
|
||
A combination of in-memory caching (for frequently accessed data) and file-based
|
||
caching (for larger content that doesn't need to be loaded on every request).
|
||
rationale: >
|
||
This hybrid approach ensures good performance for both frequently accessed
|
||
data and larger content while maintaining a reasonable memory footprint.
|
||
- question: How will security be implemented?
|
||
decision: >
|
||
Security will be implemented through a combination of input validation,
|
||
authentication, authorization, and secure storage practices. Plugins will be
|
||
subject to automated security audits during installation.
|
||
rationale: >
|
||
A layered security approach ensures that multiple attack vectors are covered,
|
||
with special attention to preventing code injection and unauthorized access.
|
||
- question: >
|
||
`in_scope` and `out_of_scope` were both still empty. What is explicitly IN scope
|
||
for v1 and what is explicitly OUT of scope for v1?
|
||
decision: >
|
||
`in_scope` and `out_of_scope` have been populated (see lists above): Page
|
||
Builder, Role Based Auth, User Management, Blog plugin, Media Manager,
|
||
Theme/Plugin Editor, i18n, Comments, Backup/Restore, and Search are in scope
|
||
for v1; multi-tenant/SaaS deployment, a plugin marketplace, and native mobile
|
||
apps are out of scope.
|
||
rationale: >
|
||
Gives a concrete, at-a-glance v1 boundary to plan milestones against instead of
|
||
inferring scope from `features_overview.notes`.
|
||
- question: What backup strategy is supported in v1?
|
||
decision: Manual trigger only via Admin UI, no automatic or scheduled backups.
|
||
rationale: >
|
||
The feature notes specify that backups are not automated; they must be triggered
|
||
manually by an admin action. |