VIBE-159 Add confirm upload details page - #43
Merged
Conversation
Contributor
🎭 Playwright E2E Test Results224 tests 224 ✅ 4m 40s ⏱️ Results for commit 9133383. ♻️ This comment has been updated with latest results. |
…e/VIBE-159-confirm-upload-details
…159-confirm-upload-details
KianKwa
changed the base branch from
master
to
feature/VIBE-158-manual-upload-form
November 3, 2025 09:14
KianKwa
changed the base branch from
feature/VIBE-158-manual-upload-form
to
master
November 3, 2025 10:58
…159-confirm-upload-details # Conflicts: # libs/admin-pages/src/pages/manual-upload/index.ts
KianKwa
changed the base branch from
master
to
feature/VIBE-158-manual-upload-form
November 4, 2025 15:50
junaidiqbalmoj
changed the base branch from
feature/VIBE-158-manual-upload-form
to
master
November 6, 2025 11:53
…nfirm-upload-details
|
junaidiqbalmoj
approved these changes
Nov 6, 2025
SarahLittlejohn
added a commit
that referenced
this pull request
Jun 9, 2026
Add a scheduled workflow (04:00 UTC, after the nightly E2E run) that keeps the requirements DB in sync with GitHub Project #43. It builds the current DB, reads the live board via the existing GitHub App token (gh api graphql), and has Claude write a numbered migration capturing drift, then opens a PR for human review. Nothing enters the source of truth unreviewed. Drift detected: new requirements crossing the Refined gate, board status changes, and implementation changes (merged closing PRs -> impl_commit_sha / impl_paths). Out of scope: title/statement/priority edits. Mirrors claude.yml (App token, AWS OIDC, Bedrock Opus) and nightly.yml (schedule, node setup). Installs sqlite3 (not present in CI by default). The prompt mandates: no PR when there is no drift; never hard-delete or down-status a requirement; treat NULL-vs-NULL impl as no change (most requirements have no merged PR). A final build + PRAGMA integrity_check/foreign_key_check step runs independently of Claude so a malformed migration cannot sit in a green PR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SarahLittlejohn
added a commit
that referenced
this pull request
Jun 18, 2026
Reconciles the requirements baseline with the live state of GitHub Project #43 as of 2026-06-18, as migration 002: - 3 new requirements: REQ-0135 (#569), REQ-0136 (#716), REQ-0137 (#729) - 6 status changes: REQ-0105, 0107, 0109, 0112, 0121, 0132 - 4 status + impl changes: REQ-0111, 0119, 0133, 0134 (now verified, with merged-PR commit sha and impl_paths) - 4 regressions recorded as status_changed history (DOORS-faithful): REQ-0126 -> draft, REQ-0129/0130/0131 -> proposed; flagged for review DB builds clean at 137 requirements; integrity_check ok and foreign_key_check empty. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
junaidiqbalmoj
added a commit
that referenced
this pull request
Jul 3, 2026
* feat: add requirements database schema Add standalone SQLite schema for tracking requirements with IBM DOORS-style traceability and change control. Three tables: requirement (core object with GitHub issue origin and implementation refinement), requirement_link (typed directional traceability with suspect flagging), and requirement_change (append-only field-level change log). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: load historic requirements from GitHub issues Populate the requirements database with 134 requirements derived from cath-service GitHub issues that have moved to "Refined Tickets" or beyond on the CaTH Kanban board (project 43). - seed.sql: 134 requirement rows (REQ-0001..REQ-0134, ordered by issue number) plus one 'created' change row each. Generated from the board and issues, not hand-edited; later changes go in migrations/. - schema.sql: add 'in_progress' status (distinguishes ready-to-pick-up from in-flight work); replace MoSCoW priority with the repo's actual label scale (highest/high/medium/low/lowest); add nullable granularity (epic/story/task). - scripts/init_db.sh builds the SQLite DB (schema -> seed -> migrations); new_migration.sh scaffolds numbered migrations. - requirements:build yarn script wraps init_db.sh. - gitignore requirements/*.db (build artefact; rebuilt from SQL). - biome: ignore .claude/ so the post-write hook stops tripping on worktrees. kind classified from ticket content (113 functional, 12 constraint, 9 non_functional). priority/granularity from labels, NULL where absent. requirement_link left empty: cross-references were not trivially typeable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: add requirement links and code traceability to seed Populate requirement_link and the impl_* columns, both derived from real GitHub data rather than inferred from topic similarity. - requirement_link: 21 links. 16 derives_from from native GitHub sub-issue parents (where both ends are in the loaded set); 5 depends_on from cross-references verified in the issue bodies. Topic-similarity links were deliberately not invented. - impl_commit_sha / impl_paths: from each issue's merged closing PR(s). impl_paths is the union of source files across all merged PRs (lockfiles, CI, helm, docs and generated files filtered out); impl_commit_sha is the latest merge commit. Only 19 of 134 have a merged PR — the migrated JIRA tickets were closed administratively and carry no commit trace. This lets the DB answer both "what is this requirement connected to" and "which code is affected by this requirement". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: add inferred semantic links with provenance tracking Add 66 content-derived traceability links between requirements, kept strictly separable from the 21 structural (fact) links. Schema: - requirement_link gains origin (github_subissue/issue_reference/inferred), confidence, and rationale columns. Structural links are facts; inferred links are judgement and carry is_suspect=1 until a human confirms them. - seed.sql structural links now record their origin (16 github_subissue, 5 issue_reference). migrations/001_inferred_links.sql: - 66 links (57 depends_on, 9 refines) derived from requirement content by a multi-agent analysis: cluster into feature areas -> propose links per cluster -> adversarial verification (each candidate had to survive a skeptic defaulting to rejection). 35 high-confidence (>=0.8). - All origin='inferred', is_suspect=1, with confidence + rationale so they can be reviewed (WHERE origin='inferred' ORDER BY confidence DESC), confirmed (is_suspect=0), or rejected (DELETE) individually. The 21 structural links are untouched. Querying the graph now answers "what is connected to this requirement" with verified and proposed links distinguishable by origin. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: add nightly requirements-sync workflow Add a scheduled workflow (04:00 UTC, after the nightly E2E run) that keeps the requirements DB in sync with GitHub Project #43. It builds the current DB, reads the live board via the existing GitHub App token (gh api graphql), and has Claude write a numbered migration capturing drift, then opens a PR for human review. Nothing enters the source of truth unreviewed. Drift detected: new requirements crossing the Refined gate, board status changes, and implementation changes (merged closing PRs -> impl_commit_sha / impl_paths). Out of scope: title/statement/priority edits. Mirrors claude.yml (App token, AWS OIDC, Bedrock Opus) and nightly.yml (schedule, node setup). Installs sqlite3 (not present in CI by default). The prompt mandates: no PR when there is no drift; never hard-delete or down-status a requirement; treat NULL-vs-NULL impl as no change (most requirements have no merged PR). A final build + PRAGMA integrity_check/foreign_key_check step runs independently of Claude so a malformed migration cannot sit in a green PR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: address CodeRabbit review — schema guards and workflow hardening - schema.sql: CHECK(json_valid(impl_paths)) so the nightly sync's LLM-written JSON can't corrupt downstream json_each queries; CHECK confidence in [0,1] matching the inferred-link semantics. Both verified against existing data (no violations) and confirmed to reject bad input. - schema.sql: comment clarifying change_type='deleted' is reserved for manual operations and intentionally unused by the automated sync. - requirements-sync.yml: persist-credentials: false on checkout; set the App token on the origin remote explicitly in Configure Git so the bot push still works without git storing credentials in .git/config. Declined (out of scope / low value): SHA-pinning actions (kept @v6 tags to match the repo's other workflows), package.json exact-pinning of pre-existing deps, timestamp GLOB CHECK, and init_db.sh glob-ordering tweak. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: sync requirements DB with GitHub board (2026-06-18) Reconciles the requirements baseline with the live state of GitHub Project #43 as of 2026-06-18, as migration 002: - 3 new requirements: REQ-0135 (#569), REQ-0136 (#716), REQ-0137 (#729) - 6 status changes: REQ-0105, 0107, 0109, 0112, 0121, 0132 - 4 status + impl changes: REQ-0111, 0119, 0133, 0134 (now verified, with merged-PR commit sha and impl_paths) - 4 regressions recorded as status_changed history (DOORS-faithful): REQ-0126 -> draft, REQ-0129/0130/0131 -> proposed; flagged for review DB builds clean at 137 requirements; integrity_check ok and foreign_key_check empty. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: ship and tickets commands * feat: comments impl * feat: add local read-only GitHub MCP server for dev sessions Add .mcp.json pointing at GitHub's hosted MCP server (read-only, scoped to issues/pull_requests/repos/projects). run.sh exports GITHUB_MCP_TOKEN from the already-authenticated gh CLI — ephemeral, never written to disk. CI is unchanged and continues to use the gh CLI directly. Documented in docs/GITHUB_MCP.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: add requirement-linking workflow for semantic traceability Multi-agent workflow that infers traceability links between requirements: cluster into feature areas -> propose candidate links per cluster -> adversarially verify each candidate. Output is inserted into the requirements DB as origin='inferred', is_suspect=1 links (see migrations/001_inferred_links.sql). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat: add inferred links for GitHub-synced requirements 135-137 Two inferred traceability links for the requirements added by the 002 GitHub sync, derived from live issue text read via the GitHub MCP server: 135 -> 127 depends_on (storage.tf presupposes the bootstrap Key Vault infra) 137 -> 86 refines (footer font size refines the header/footer update) Both origin='inferred', is_suspect=1, following 001's conventions. None of the three new issues (569/716/729) has sub-issues, so there are no structural links to record. Weak topic-only candidates were considered and dropped (documented in the migration header). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: qk-ship ticket verification and concise plan --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Matt <56436664+matt2415@users.noreply.github.com> Co-authored-by: junaidiqbalmoj <84805836+junaidiqbalmoj@users.noreply.github.com>
4 tasks
hmctsclaudecode Bot
pushed a commit
that referenced
this pull request
Jul 9, 2026
10 STATUS + IMPL changes (closed issue + merged closing PR → verified): REQ-0078 (#301): implemented → verified (PR #458) REQ-0105 (#428): in_progress → verified (PR #749) REQ-0106 (#429): approved → verified (PR #761) REQ-0107 (#431): implemented → verified (PR #701) REQ-0108 (#434): approved → verified (PR #772) REQ-0109 (#436): implemented → verified (PR #727) REQ-0112 (#467): implemented → verified (PR #670) REQ-0124 (#563): approved → verified (PR #782) REQ-0135 (#569): in_progress → verified (PR #748) REQ-0137 (#729): approved → verified (PR #766) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
SarahLittlejohn
added a commit
that referenced
this pull request
Jul 14, 2026
chore(requirements): sync GitHub Project #43 state as of 2026-07-04
This was referenced Jul 16, 2026
This was referenced Jul 23, 2026
hmctsclaudecode Bot
pushed a commit
that referenced
this pull request
Jul 25, 2026
Supersedes the 2026-07-24 migration with an expanded delta that picked up 2 additional closed issues (#593, #699) missed by the prior run. Delta: - 3 new requirements: REQ-0157 (#593), REQ-0158 (#699), REQ-0159 (#859) - 2 status changes: REQ-0098 approved→verified, REQ-0099 implemented→verified - 1 impl change: REQ-0099 gained merged PR Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This was referenced Jul 28, 2026
SarahLittlejohn
added a commit
that referenced
this pull request
Aug 4, 2026
…ith board The nightly requirements-sync Action ran with a GitHub App token that cannot read Project #43: HMCTSClaudeCode declares repository_projects (Projects classic) but no organisation Projects permission, and ProjectV2 is an org-scoped resource. The ProjectV2 query returned FORBIDDEN, and rather than stopping, the job substituted "issue closed + merged closing PR" as a proxy for board status. That proxy cannot see open issues, so every ticket in Refined Tickets was invisible to it. Migrations 004-010 each shipped carrying "Board access unavailable / HUMAN REVIEW REQUIRED", the run exited green every night, and the database fell 126 requirements behind the board. Rather than widen an org-wide App's permissions to fix an unattended job, move the sync to an interactive command where a developer's own token already has read:project. - Delete .github/workflows/requirements-sync.yml. - Add requirements/scripts/fetch_board.sh: pages the board and maps each column to a status. Exits non-zero if the board is unreadable, including the data.node == null case a token without projects access actually returns instead of an HTTP error. An unreadable board now stops the run. - Add requirements/scripts/generate_sync_migration.ts: emits the delta as SQL, exits 1 when there is none. Output is deterministic, so a rerun on unchanged input regenerates byte-identical SQL. - Add /qk-requirements-sync, which fetches the board, generates the migration, infers requirement_link rows for new requirements, verifies the mirror is exact, and opens a PR. - Add migration 011: 127 new requirements (REQ-0160..REQ-0286), 25 updated. Every board issue now has a matching row with a matching status. The column mapping covers the whole board, not just Refined Tickets and beyond. Backlog maps to draft and Prioritised Backlog to proposed, matching what seed.sql already did for those columns, so a ticket moving backwards is mirrored like any other move and recorded in requirement_change. The old never-down-status rule existed to protect against guessed data; with a readable board it just held the database out of date. /qk-tickets: its query referenced story_points and assigned_to, which are not columns in schema.sql, so it errored out entirely; it also described 'blocks' and 'related_to' link types that are not in the CHECK constraint. Group by priority instead, use the real link types, and add a source argument so it can read either master or an open sync PR's migration. It now also works out which approved tickets are safe to run in parallel. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira link
https://tools.hmcts.net/jira/browse/VIBE-159
Change description
Add confirm upload details page