27 lines
1.4 KiB
YAML
27 lines
1.4 KiB
YAML
|
decisions_log:
|
||
|
|
- question: How should plugins be installable by end users?
|
||
|
|
decision: >
|
||
|
|
Plugins are installable via ZIP file upload to the system.
|
||
|
|
rationale: >
|
||
|
|
ZIP upload keeps module installation accessible to admins without CLI or
|
||
|
|
Composer access.
|
||
|
|
- question: >
|
||
|
|
The `features` list itself was empty while all the actual feature content lived
|
||
|
|
in `notes`. Should `features` be populated with a concise catalog for
|
||
|
|
at-a-glance scanning?
|
||
|
|
decision: >
|
||
|
|
Yes — `features` has been populated. User Management and Role Based Auth
|
||
|
|
Management were also added to the list above, since they were documented in
|
||
|
|
`app.notes`/`auth_requirements`/`scope.in_scope` but missing from this catalog.
|
||
|
|
rationale: >
|
||
|
|
Keeps `features` a complete, scannable catalog rather than a partial list that
|
||
|
|
only covers items that happened to also get `notes`.
|
||
|
|
- question: >
|
||
|
|
Akismet was the only spam-protection measure named for the Comments System;
|
||
|
|
should a fallback be added in case Akismet is unavailable or insufficient?
|
||
|
|
decision: >
|
||
|
|
Yes — honeypot and rate-limiting have been added alongside Akismet (see
|
||
|
|
`notes.Comments System` above).
|
||
|
|
rationale: >
|
||
|
|
Layers a bot-trap and a submission-frequency cap on top of the third-party
|
||
|
|
Akismet service so spam protection doesn't have a single point of failure.
|