Git Client: Final Verification, Accessibility, Visual Regression, Docs, and Closure Evidence

[oscharko]

Parent Epic: #1571

Purpose

Prove the completed Git client is production-ready and close the epic with deterministic evidence across unit, integration, a11y, visual, e2e, security, and documentation gates.

Epic And Board Placement

• Parent Epic: #1571 is present and points to the governing open epic.
• This issue is linked as a GitHub sub-issue of the parent epic, not only referenced in Markdown.
• This issue appears under the parent epic swimlane on the public Keiko Product Delivery board.
• Project fields are set before handoff: Classification: Task, Status: Open Issues, Workflow State: New or Triaged, inherited or explicit Priority, and Human Review Required: Yes.
• The parent epic remains Classification: Epic, Status: Open Epics, and positioned in the board's top-to-bottom implementation order.
• Card Chat or conversation-card work uses this same parent/sub-issue and board placement flow; do not create loose chat/card issues outside an epic swimlane.

Agent Execution Mode

• Single-agent
• Agent team
• Audit-only
• Refactor-only
• Feature delivery
• Audit/verification-heavy
• Human-led / agent-assisted

Agent Routing Hints

• Lead agent: coordinator | developer | architect | pr-shepherd.
• Suggested specialist agents: explorer | implementor | test-engineer | security-reviewer | performance-engineer | a11y-auditor | docs-editor | docs-writer | verifier | pr-reviewer | pr-shepherd.
• Primary area label: area:repository-context or area:user-interface, as set on this issue.
• Expected write ownership: limited to the modules required by this issue; coordinator must prevent parallel agents from editing overlapping Git UI, BFF Git routes, or Git tool contracts.

Existing Capability Review

• Existing Keiko packages, UI surfaces, server routes, contracts, validation helpers, evidence models, workflow state, and tool/workspace boundaries were inspected before implementation.
• The issue identifies what will be reused, extended, generalized, replaced, or left untouched.
• Any new implementation is justified as a real capability gap, not a parallel implementation of existing behavior.
• Refactoring or consolidation was considered when existing functionality is close but not yet shaped for this issue.

Delivery Board Workflow

• Add this issue to the public Keiko Product Delivery project before work starts.
• Set project Classification to Task.
• Set project Status to Open Issues while the issue is open and unclaimed.
• Confirm this issue is visible under the parent epic swimlane through the GitHub sub-issue relationship.
• Keep Workflow State current: New, Triaged, In Progress, PR Open, Ready for Human Review, Blocked, Waiting for User, or Done.
• When an agent starts work, set the issue label to status: in progress, set project Status and Workflow State to In Progress, and fill Owner / Agent.
• When implementation starts, fill the Branch field with the active branch name.
• When a PR is opened, set Workflow State to PR Open, fill Pull Request, and keep Human Review Required set to Yes.
• When the PR is ready for maintainer review, set Workflow State to Ready for Human Review and replace the issue label with status: ready for human review.
• Do not mark Done until the PR is merged, closure evidence exists, the issue is closed, and project Status is set to Done.

Expected Verification

• Required GitHub check: ci.
• Server/unit tests cover Git parsers, routes, validation, redaction, timeouts, missing Git, unsafe repo, no remote/upstream, detached HEAD, conflicts, fetch/pull failures.
• UI/component tests cover repository selector, clone/open sheet, changes list, diff pane, staging, commit composer, branch dropdown, history tab, sync button, PR/merge panels, and agent affordances.
• A11y tests cover keyboard-only operation for toolbar, repository selector, branch selector, tabs, file list, diff pane, commit controls, modals, and outcome alerts.
• Playwright e2e and visual screenshots cover full Git workflows and constrained window sizes.
• Security/governance review confirms mutating operations stay behind BFF/tooling authority, CSRF, preview/evidence, redaction, and credential boundaries.

Review Settlement and Formal Issue Completion

• The implementation PR waits for required GitHub checks before merge.
• All actionable review findings are fixed or explicitly dispositioned in the PR before merge.
• Acceptance Criteria and Expected Verification checkboxes are updated only when evidence exists.
• Delivery board fields are updated before handoff, including Owner / Agent, Branch, Pull Request, and Human Review Required.
• Required documentation, PR evidence, issue comments, migration notes, screenshots, logs, or follow-up issues are completed when requested by this issue.
• The issue remains open until implementation is merged, review findings are settled, and closure evidence is recorded.

Stop Conditions

• Stop if the implementation would expand beyond this issue's stated scope.
• Stop if required acceptance criteria are missing, contradictory, or no longer match the linked epic.
• Stop if the work requires secrets, customer data, private runtime logs, or token-bearing artifacts.
• Stop if two parallel agents would need to edit the same file scope.
• Stop if existing Keiko functionality can satisfy the issue outcome through reuse, extension, or generalization; update the issue or PR with the reuse plan instead of implementing a duplicate subsystem.
• Stop if the change would weaken architecture boundaries, quality gates, security posture, evidence semantics, deterministic verification, or required ci guarantees.
• Stop after three CI or review-finding repair attempts with different root causes and report the blocker.

Language and Professional Standard

• All issue work, PR descriptions, code comments, configuration properties, schema fields, README updates, Markdown files, and GitHub comments must be written in professional English.
• Use accurate enterprise product terminology; when limitations exist, state them precisely without prototype-only, placeholder, fake, or informal framing.
• Build production-ready, state-of-the-art solutions while keeping implementation simple, maintainable, and focused on the issue scope.
• Be creative and innovative where it improves product quality, but avoid unnecessary special cases, speculative abstractions, and process overhead.

Scope

Add or refresh unit, component, a11y, Playwright e2e, screenshot, documentation, and closure evidence for the full Git client. Use local bare-repository fixtures for clone/fetch/pull/push scenarios and avoid real credentials in CI.

Out of Scope

No new product capability beyond testability/docs fixes required to close the epic; no deferred feature work hidden inside verification; no real external provider credentials in automated CI.

Deliverables

• Unit, component, a11y, and Playwright e2e coverage is complete for the Git client.
• Local bare-repository fixtures cover clone/fetch/pull/push scenarios without real credentials.
• Browser screenshots are captured for desktop and constrained/mobile-ish window sizes.
• Documentation covers Git credentials, repository manager behavior, agent operation boundaries, and MIT attribution if code was copied.
• Final closure evidence is recorded in this issue or the parent epic.

Acceptance Criteria

• Required ci passes.
• Studio visual regression and accessibility gates cover the new Git surface.
• E2E verifies clone/open, repository select, changes/diff, stage, commit, branch create/switch, history, fetch/pull/push state, PR/merge entry, and error states.
• Final evidence records reuse/extension decisions and confirms no visible governance language remains in the Git client.

Engineering Notes

This is the closure gate. If earlier child issues leave undocumented gaps, this issue must either close them with evidence or explicitly create follow-up issues and record why they are outside the epic's complete-delivery promise.