docs(09): resolve research planning rules
This commit is contained in:
@@ -260,17 +260,17 @@ if err := dec.Decode(&schema); err != nil {
|
|||||||
|
|
||||||
| # | Claim | Section | Risk if Wrong |
|
| # | Claim | Section | Risk if Wrong |
|
||||||
|---|-------|---------|---------------|
|
|---|-------|---------|---------------|
|
||||||
| A1 | Add an admin login throttle using the Phase 7 shape if its extraction is low-cost. This is explicitly discretionary, not a locked decision. | Security / Open Questions | A later plan must schedule hardening before exposing admin login. |
|
| A1 | Admin-login throttling is an executable planning rule: reuse/extract the Phase 7 throttle when low-cost; otherwise make the omission a named security-review finding. | Security / Open Questions (RESOLVED) | The plan cannot silently omit hardening. |
|
||||||
| A2 | Create the singleton settings row on first write rather than read, to keep GET side-effect-free. | Open Questions | A caller expecting a persisted row on GET needs an explicit decision. |
|
| A2 | Create the singleton settings row on first write so GET remains side-effect-free. | Open Questions (RESOLVED) | A caller requiring a persisted row on GET would need a future explicit change. |
|
||||||
|
|
||||||
## Open Questions
|
## Open Questions (RESOLVED)
|
||||||
|
|
||||||
1. **How should field-level `rules:` compose with model `Rules()`?**
|
1. **How should field-level `rules:` compose with model `Rules()`?**
|
||||||
- What we know: model `Rules()` and `lagoon.Validate` are the existing backstop; D-06 requires YAML `required: true` to yield 422 at minimum. [VERIFIED: lagoon/validate.go:22-40; 09-CONTEXT.md:49]
|
- What we know: model `Rules()` and `lagoon.Validate` are the existing backstop; D-06 requires YAML `required: true` to yield 422 at minimum. [VERIFIED: lagoon/validate.go:22-40; 09-CONTEXT.md:49]
|
||||||
- Recommendation: parse only `required` in Phase 9, merge it into the model rules without allowing YAML to relax model rules, and defer richer YAML rule grammar until a real port needs it.
|
- **RESOLVED:** Parse only YAML `required` in Phase 9 and merge it additively with model `Rules()`; YAML must never relax or replace a model rule. Defer richer YAML rule grammar until a ported plugin needs it. [VERIFIED: 09-CONTEXT.md:49]
|
||||||
2. **Should admin login throttling ship here?**
|
2. **Should admin login throttling ship here?**
|
||||||
- What we know: it is discretionary; OWASP ASVS calls for documented anti-automation controls and successful/failed auth event logging. [VERIFIED: 09-CONTEXT.md:50] [CITED: https://cornucopia.owasp.org/taxonomy/asvs-5.0/06-authentication/01-authentication-documentation] [CITED: https://cornucopia.owasp.org/taxonomy/asvs-5.0/16-security-logging-and-error-handling/03-security-events]
|
- What we know: it is discretionary; OWASP ASVS calls for documented anti-automation controls and successful/failed auth event logging. [VERIFIED: 09-CONTEXT.md:50] [CITED: https://cornucopia.owasp.org/taxonomy/asvs-5.0/06-authentication/01-authentication-documentation] [CITED: https://cornucopia.owasp.org/taxonomy/asvs-5.0/16-security-logging-and-error-handling/03-security-events]
|
||||||
- Recommendation: reuse/extract the Phase 7 throttle in the auth-foundation plan if practical; otherwise record it as an explicit security-review finding rather than silently deferring it.
|
- **RESOLVED:** The auth-foundation plan must reuse/extract the Phase 7 throttle when doing so is low-cost. If that extraction is not low-cost, the security-review plan must contain a named finding for admin-login throttling; it cannot be silently omitted. [VERIFIED: 09-CONTEXT.md:50]
|
||||||
|
|
||||||
## Environment Availability
|
## Environment Availability
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user