Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

F-024 S1: complete real Keycloak journeys and vendor-client evidence

Open
#483 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@Zamojski5 is already working on this.

Since Oct 11, 2026.

Assessment

This issue has not been assessed yet.

Description

Outcome: Finish the original S1 acceptance at #310 against a real Keycloak-backed Flux and real Claude Code/Codex clients. PR #384 is a bounded implementation slice; its scripted/mock client and recovery fixtures do not satisfy the remaining real integration evidence.

Owner: @Zamojski5 (claude-maurycy). Evaluator: @PelikanFix16. Milestone: complete application and release. This records existing required work; it adds no new feature or implementation branch.

Acceptance criteria (original S1 criteria unchanged):

  • S1-AC-9: Test cases 2 and 8, and the IdP-down rows of case 9, against a Keycloak-backed Flux, under the original Docker test plan and S1 contract. Preserve every assertion in those cases. Include the outstanding real fresh-browser OIDC authorization/signed continuation, CIMD and pre-registered client/redirect/consent controls, and actual boot-outage/recovery journey; intercepted provider capabilities are fixture evidence only. Case 8's token custody/backup/restore assertions compose with S4 rather than being dropped from final acceptance.
  • S1-AC-10: Real Claude Code and Codex runs against a Keycloak-backed Flux, recorded with their versions as integration evidence (PROV-5). Mock clients do not prove vendor compatibility. Retain the accepted issuer/audience, PKCE, callback and owner/grant boundaries; record actual activation/authorized tools rather than a manual ready flag or transport-only mock.
  • Evidence and parent completion: Pin the composed candidate, runtime/client versions, actual selected commands, positive/negative outcomes and protected integration. Keep credentials/tokens private and prove exact cleanup of owned test resources. Record remaining/unavailable checks honestly. #310 remains open until every original S1-AC-1–AC-10 is verified in the integrated application; this child does not certify full PWA/native/backup/release acceptance by itself.

Dependencies: #384 → #392 → #418 and the admitted SSO/custody candidate for the cases that require those slices. Coordinate actual client/protocol evidence with #460/#467 and PROV-5/#179; a separate scripted client result cannot substitute for vendor-client evidence. The complete original contracts remain authoritative.

Current evidence boundary: prior #384 source 05678de8 has 16 API checks, 27 real-Keycloak/bad-token/restart checks and one recovery UI fixture; current main90 composition/ordinary upgrade is being verified at f7327db3de6d05be3a30ae2396ff6690fd0d2c4a. Those counts retain their original pins and do not establish all AC-9/AC-10. This task preserves the remaining criteria while the existing PR is integrated; no new implementation is claimed or started here.

Ownership handoff, 2026-10-11 (explicit founder request): remaining implementation → Zamojski5; independent evaluator → PelikanFix16. Original criteria and v0.1 requirements are unchanged. Historical own PRs #384/#386 retain their existing authorship and branches; use a separate owner-controlled branch for the remaining outcome. See the linked handoff for immediately independent work and dependencies.

Dominant language
TypeScript
Stars
3
Forks
0
Avg merge
18h 3m
Merged PRs (30d)
254

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ColdPhase/flux

All issues in ColdPhase/flux

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.