feat: 문서 구조 변경 및 tech-visual 스킬 추가
This commit is contained in:
DongHyeonka
@@ -0,0 +1,163 @@
|
||||
# Quality report
|
||||
|
||||
## Gate result
|
||||
|
||||
**PASS**
|
||||
|
||||
- Document type: `technical_blog`
|
||||
- Reader language: `ko-KR`
|
||||
- Citation mode: `hidden`
|
||||
- Source pack: 48 entries
|
||||
- Required H2 intents: 8/8, in contract order
|
||||
- Deterministic lint: 100.0/100
|
||||
- ClariDoc word count: 9,043
|
||||
- Blockers: 0
|
||||
- Errors: 0
|
||||
- Warnings: 0
|
||||
|
||||
No mock-provider score is used as evidence of prose or factual quality.
|
||||
|
||||
## Evidence collection
|
||||
|
||||
All four pattern tips were inspected independently and read-only:
|
||||
|
||||
| Pattern | Git tip |
|
||||
|---|---|
|
||||
| AP1 | `bb8fd9333d7da1c6424d6e0b039fc1c80c2cf0ca` |
|
||||
| AP2 | `d019846f8725bdb0badde33043b020dc252e32ff` |
|
||||
| AP3 | `934c5da5d6edc2429dfb558b773656e46f21d677` |
|
||||
| AP4 | `f4aea65dc6255eae07b20ebbe21e02fb6115e563` |
|
||||
|
||||
The canonical `develop` corpus was merged with branch-specific implementation,
|
||||
configuration, test-contract, decision-rationale, and worked-flow evidence. The
|
||||
expanded evidence covers browser entry, authorization callback, token/session
|
||||
storage, controller and framework transformations, downstream requests, exact
|
||||
reader JSON fields, failure statuses, and implementation gaps.
|
||||
|
||||
The common comparison described AP2 as a short or one-time handoff, but the
|
||||
current controller returns the raw Keycloak access token on repeatable
|
||||
authenticated GET requests and has no nonce consumption or deletion. The
|
||||
article therefore uses the implementation-backed term `access-only handoff`.
|
||||
|
||||
## Reference-document calibration
|
||||
|
||||
The requested comparison document was inspected for its authoring pattern. Its
|
||||
important technique is a concrete initial HTTP input followed through actual
|
||||
classes and methods, intermediate models, next-hop input, and observable final
|
||||
output. The revised Keycloak article applies the same technique separately to:
|
||||
|
||||
- AP1 login callback and browser Bearer `/api/me`;
|
||||
- AP2 login session, `/token/boundary`, `/token/access`, and direct API call;
|
||||
- AP3 login, `/bff/api/me`, CSRF issuance, and preference POST;
|
||||
- AP4 login redirect, Nginx auth subrequest, upstream rewrite, and identity JSON.
|
||||
|
||||
## Independent reviews and revisions
|
||||
|
||||
### AP1 and AP2 technical review
|
||||
|
||||
Initial result: **NEEDS REVISION**
|
||||
|
||||
Material findings:
|
||||
|
||||
- the general Authorization Code introduction implied that every pattern used a
|
||||
`code_challenge`, contradicting AP2's unverified PKCE boundary;
|
||||
- the AP1 browser E2E was said to assert `username`, while its live assertion is
|
||||
UI status plus decoded audience;
|
||||
- AP2's `AP2_SESSION` transaction role before callback was missing;
|
||||
- CORS wording could be mistaken for network-level access control;
|
||||
- dynamic audience examples looked exact;
|
||||
- AP1's local wildcard redirect registration and the diagnostic-server negative
|
||||
test shape were not explicit.
|
||||
|
||||
All findings were revised. Targeted re-review result: **PASS**, with no remaining
|
||||
blocker, error, or warning.
|
||||
|
||||
### AP3 and AP4 technical review
|
||||
|
||||
Initial result: **NEEDS REVISION**
|
||||
|
||||
Material findings:
|
||||
|
||||
- AP3 incorrectly placed the ID token in
|
||||
`OAuth2AuthorizedClientService`; the corrected text separates access/refresh
|
||||
token storage from the ID-token-derived OIDC principal in `SecurityContext`;
|
||||
- AP4 was initially grouped with server-side session cookies and was assigned
|
||||
persistent refresh-token custody; the corrected text describes the configured
|
||||
minimal client-side cookie, absence of a shared server store, and the
|
||||
unverified refresh lifecycle;
|
||||
- the AP3 handler was named `updatePreferences` instead of the actual
|
||||
`updatePreference`;
|
||||
- the cross-site test was described beyond its exact assertion, which only
|
||||
checks that `AP3_SESSION` is absent from the request.
|
||||
|
||||
All findings were revised. Targeted re-review result: **PASS**, with no adjacent
|
||||
regression found.
|
||||
|
||||
### Reader, logic, evidence, and procedure review
|
||||
|
||||
Initial result: **PASS WITH ONE WARNING**
|
||||
|
||||
The only warning was that “oauth2-proxy manages the Keycloak session” could
|
||||
confuse the IdP SSO session with AP4's proxy session. The sentence now says that
|
||||
oauth2-proxy owns OIDC code exchange and `AP4_SESSION` verification while Nginx
|
||||
owns upstream request and identity-header construction.
|
||||
|
||||
The reviewer confirmed that:
|
||||
|
||||
- all four patterns contain a complete
|
||||
`input → transformation → next hop → output` trace;
|
||||
- test-defined contracts remain separate from fresh execution claims;
|
||||
- hidden source metadata does not leak into reader prose;
|
||||
- destructive volume reset is surrounded by prerequisites, stop conditions,
|
||||
backup, and recovery guidance;
|
||||
- each choice includes context, rationale, alternative, accepted cost,
|
||||
guardrail, and evidence boundary.
|
||||
|
||||
## Validation performed
|
||||
|
||||
- Brief and 48-entry SourcePack runtime validation: **PASS**
|
||||
- Deterministic preliminary outline generation: **PASS**
|
||||
- Refined outline contract: **PASS**, 8 required intents in order
|
||||
- Every refined-outline evidence ID resolves in the SourcePack: **PASS**
|
||||
- Reader/provenance separation and hidden-citation leakage lint: **PASS**
|
||||
- Final deterministic document lint: **PASS**, 100.0/100, 0 issues
|
||||
- ClariDoc unit and integration suite: **PASS**, 41 tests
|
||||
- Target repository after inspection: clean `develop`
|
||||
- Four remote pattern refs re-resolved to the reviewed Git tips: **PASS**
|
||||
- Earlier read-only manifest/ref audit: 39 declared feature refs exist and are
|
||||
reachable from their declared target branches
|
||||
|
||||
## Validation deliberately not performed
|
||||
|
||||
The pattern verification scripts rebuild their stacks after deleting Docker
|
||||
volumes. They were not run during this documentation task. The article therefore
|
||||
describes committed acceptance contracts rather than claiming a fresh runtime
|
||||
PASS.
|
||||
|
||||
The repository-provided branch audit still depends on a branch-note inventory
|
||||
outside the available local path. The separate read-only Git reachability check
|
||||
does not substitute for those missing note files.
|
||||
|
||||
The ClariDoc `scripts/verify.sh` workflow was not run because this worktree
|
||||
already contains extensive user changes and that workflow removes or rebuilds
|
||||
distribution and generated demo artifacts. The non-destructive 41-test suite,
|
||||
contract validation, outline validation, and final lint were run instead.
|
||||
|
||||
## Remaining evidence boundaries
|
||||
|
||||
- AP1's E2E does not directly assert the token-request `code_verifier`, automatic
|
||||
silent renewal, exact IdP cookie flags, CORS preflight, invalid signature, or
|
||||
expired-token negative cases. Its local realm uses wildcard redirects.
|
||||
- AP2 does not implement one-time consumption and does not verify expiry-driven
|
||||
refresh, logout, durable session/token storage, or handoff replay rejection.
|
||||
- AP3 does not implement a shared session/token store, token-at-rest encryption,
|
||||
coordinated logout, downstream failure mapping, or user-scoped persistence
|
||||
for the preference example.
|
||||
- AP4's minimal cookie does not establish persistent refresh-token custody. Role
|
||||
propagation, generalized endpoint enforcement, state-changing-request CSRF,
|
||||
multi-replica cookie-secret lifecycle, and internal secret rotation remain
|
||||
outside the verified contract.
|
||||
- The Google harness uses a controllable mock identity provider. Real external
|
||||
accounts and public-HTTPS acceptance remain separate.
|
||||
- Performance, load, high availability, recovery, and long-duration session
|
||||
behavior are outside the verified scope.
|
||||
Reference in New Issue
Block a user