jobtrackingapp/automation/prompts/prompt 11 - release readiness.txt

# JOBBJAKT — MASTER RELEASE READINESS, REMEDIATION & PRODUCTION ACCEPTANCE

## YOUR ROLE

Act as an independent software release engineering team consisting of:

- Principal software architect
- Senior .NET backend engineer
- Senior React/TypeScript frontend engineer
- Application security engineer
- DevSecOps and infrastructure engineer
- Database reliability engineer
- Accessibility specialist
- QA automation and regression engineer
- Performance engineer
- Site reliability engineer
- Production release manager

Your task is to determine whether **Jobbjakt is genuinely ready for a safe, secure, reliable production release**.

Do not assume the application is ready simply because development is complete or existing tests pass.

Your responsibility is to independently investigate, challenge assumptions, identify defects, remediate issues, verify the fixes, and produce a defensible release decision.

**Do not deploy, merge into production, modify production databases, or promote a release without my explicit approval.**

---

# 1. PRIMARY OBJECTIVES

Complete a comprehensive end-to-end release qualification of Jobbjakt.

The assessment must establish whether:

1. The complete application works as intended.
2. All major user workflows operate correctly.
3. UI/UX changes are consistent and accessible.
4. Authentication, authorization, and data isolation are secure.
5. The backend and frontend integrate correctly.
6. MariaDB and database migrations are reliable.
7. Background processing and integrations are robust.
8. Email, OAuth, AI, and document-generation features work correctly.
9. Docker and production configuration are safe.
10. Security vulnerabilities have been assessed and appropriately resolved.
11. Performance is acceptable under realistic workloads.
12. CI/CD provides trustworthy release evidence.
13. Backups and recovery procedures are verified.
14. Monitoring and operational diagnostics are sufficient.
15. Deployment and rollback procedures are documented and tested.
16. Existing release blockers have been resolved or explicitly dispositioned.
17. No critical or high-severity unresolved release-blocking issue remains.
18. Production release approval is justified by fresh evidence.

This is a release-readiness exercise, not a feature-development phase.

Do not introduce unnecessary features or architectural changes.

---

# 2. DISCOVER THE CURRENT APPLICATION

Begin by inspecting the actual repository and its existing documentation.

Establish the current implementation of:

- React and TypeScript frontend
- MUI and Emotion design system
- .NET backend and APIs
- Entity Framework Core
- MariaDB
- AI service and model integrations
- Authentication and authorization
- Google and Microsoft OAuth integrations
- Email providers and correspondence
- CV generation and PDF export
- CV import and document processing
- Docker Compose
- Reverse proxy and routing
- Environment configuration
- CI/CD pipelines
- Logging and monitoring
- Background services
- Data backup and recovery

Verify everything against actual code and configuration rather than relying on these descriptions.

Map each component's dependencies, failure modes, and production requirements.

Identify all public endpoints and trust boundaries.

Document differences between local development, test, staging, and production environments.

Do not access live production resources unless explicitly authorized.

---

# 3. REVIEW EXISTING RELEASE BLOCKERS FIRST

Inspect previous redesign, security, CI, qualification, and acceptance documentation.

Previously reported issues include:

- Phase 9 qualification was NO-GO.
- Phase 10 was NO-GO.
- Production was NO-GO.
- Linux PDF fidelity failed 11 of 24 fixtures.
- Python dependency advisory disposition remained open.
- Hosted MariaDB CI was blocked.
- Hosted runner isolation remained unverified.
- Human, device, and provider acceptance was incomplete.
- Other previously documented design and qualification debt may remain.

These are historical reported states, not proof of their current condition.

**Independently revalidate every item.**

For each blocker:

1. Find its original evidence.
2. Determine its current status.
3. Reproduce the issue where possible.
4. Identify its root cause.
5. Implement a focused remediation when feasible.
6. Run fresh verification.
7. Record the results.
8. Close the blocker only when supported by evidence.

Do not silently dismiss, waive, or relabel previously unresolved issues.

Document any issue that cannot be reproduced and explain the verification limitations.

---

# 4. COMPLETE FUNCTIONAL REGRESSION TESTING

Inventory every supported user journey and test it end to end.

Include, wherever implemented:

## Authentication and accounts
- Registration
- Email verification
- Login and logout
- Password reset
- Session expiration and renewal
- Invalid credentials
- Account changes
- OAuth login
- Account deletion
- Permission restrictions

## Job management
- Create applications
- Edit applications
- Delete applications
- Change application status
- Kanban interactions
- Search, sorting, and filtering
- Saved views
- Timeline and activity history
- Notes and attachments
- Follow-ups and reminders

## CV and document management
- Create CV
- Edit every supported section
- Reorder sections
- Change templates
- Import CV
- Preview CV
- Export PDF
- Manage multiple CVs
- Generate and edit cover letters
- Verify saved and exported content consistency

## AI workflows
- AI-assisted writing
- CV improvement
- Job-specific tailoring
- Text generation and regeneration
- User review and acceptance
- Invalid model responses
- Unavailable model/provider
- Timeouts
- Cancellation
- Partial failures

## Email and integrations
- Connect providers
- Refresh credentials
- Handle expired tokens
- Read supported correspondence
- Associate emails with applications
- Disconnect accounts
- Handle provider errors and rate limits

## Other features
- Dashboard
- Analytics
- Calendar
- Notifications
- Career profile
- Settings
- Administrative functionality
- Subscription and billing, if implemented

Verify persistence, error handling, and data integrity.

Test empty, loading, error, and populated states.

Do not claim coverage for workflows that were not executed.

---

# 5. FRONTEND AND UX RELEASE QUALIFICATION

Evaluate the completed modernised interface.

Check:

- Layout consistency
- Navigation
- Page hierarchy
- Typography
- Spacing
- Responsive design
- Light mode
- Dark mode
- English localization
- Norwegian localization
- Dialogs and drawers
- Tables and Kanban boards
- Forms and validation
- Loading states
- Empty states
- Error recovery
- Mobile navigation
- Touch interactions
- Cross-browser behaviour

Verify that unnecessary boxes, nested panels, and decorative containers have not returned.

Do not prioritize aesthetics over usability.

Use representative screenshot comparisons and browser automation.

Review changes against the approved design system.

Verify that UI refactoring has not removed or concealed existing functionality.

---

# 6. ACCESSIBILITY RELEASE GATE

Target WCAG 2.2 AA.

Test:

- Keyboard navigation
- Logical focus order
- Visible focus indicators
- Screen-reader compatibility
- Semantic landmarks and headings
- Accessible labels
- Colour contrast
- Text resizing
- Responsive reflow
- Target sizing
- Form errors
- Dialog focus trapping and restoration
- Menu interactions
- Drag-and-drop alternatives
- Reduced-motion support
- Accessible status announcements

Use automated accessibility tooling and manual verification.

Pay particular attention to complex application management and CV-editing workflows.

Record the relevant WCAG success criteria for each finding.

Automated accessibility tests alone do not demonstrate complete conformance.

---

# 7. COMPREHENSIVE SECURITY ASSESSMENT

Use the installed Codex security tooling or security plugin where available, along with appropriate local security tools.

Verify tooling is actually available before invoking it.

Assess the application against relevant OWASP web application and API security risks.

Investigate:

- Broken authentication
- Broken authorization
- Insecure direct object references
- Cross-user and cross-tenant data exposure
- SQL injection
- Cross-site scripting
- CSRF
- SSRF
- Command injection
- Path traversal
- Insecure file uploads
- Unsafe document parsing
- JWT configuration and validation
- OAuth state and redirect validation
- Refresh-token handling
- Session fixation
- Insecure cookies
- CORS configuration
- Security headers
- Rate limiting
- Password and account recovery security
- Secrets exposure
- Sensitive logging
- Container security
- Dependency vulnerabilities
- Supply-chain integrity
- AI prompt-injection trust boundaries

Test authorization for every relevant API operation.

Verify users cannot retrieve or alter other users' data through manipulated identifiers or requests.

Inspect both frontend and backend enforcement.

Do not mistake hidden UI controls for authorization.

Perform active testing only against explicitly authorized local or staging targets.

Use synthetic accounts and data.

Do not run destructive, denial-of-service, or credential-extraction tests against production.

Classify security findings and identify actual exploitability, affected scope, and remediation priority.

Remediate applicable release-blocking findings and retest them.

Never include real credentials, access tokens, or secret values in reports.

---

# 8. DATABASE AND DATA-INTEGRITY QUALIFICATION

Validate the actual production-target database architecture.

Check:

- EF Core migrations
- Schema compatibility
- Referential integrity
- Transaction boundaries
- Concurrency
- Data validation
- Indexes
- Query performance
- Connection pooling
- Retry behavior
- Migration repeatability
- Backup compatibility
- Database permissions
- Data retention and deletion
- Sensitive data protection

Run integration tests against real MariaDB, not only SQLite or mocks.

Test upgrade paths from the currently deployed schema.

Test migration failure and recovery using isolated database copies.

Verify that deployment does not silently destroy or corrupt user data.

Ensure that any irreversible migration has a documented recovery strategy.

---

# 9. PDF AND DOCUMENT FIDELITY

This is a specific historical release blocker and requires dedicated qualification.

Reassess:

- Linux PDF generation
- Fonts
- Page breaks
- Margins
- Pagination
- Section ordering
- Template fidelity
- Print output
- Special characters
- Norwegian characters
- Long text
- Large CVs
- Empty sections
- Image handling
- Output determinism

Investigate the previously failing fixtures and expand the suite when gaps are identified.

Compare actual output against approved references using appropriate methods and tolerances.

Do not update baselines merely to make tests pass.

If a baseline is genuinely incorrect, document why and obtain approval before replacing it.

Ensure production-equivalent Linux/container verification passes before claiming readiness.

---

# 10. PERFORMANCE AND RELIABILITY

Establish measurable baselines and appropriate acceptance thresholds.

Evaluate:

- Initial page load
- Navigation responsiveness
- API latency
- Database query performance
- Large application lists
- Filtering and sorting
- Kanban performance
- CV editor responsiveness
- PDF generation time
- AI request handling
- Memory usage
- Container resource usage
- Concurrent users
- Error rates
- Background task reliability

Use realistic synthetic datasets and repeatable test scenarios.

Define load targets from documented requirements or explicitly label proposed targets pending approval.

Investigate N+1 queries, excessive frontend re-rendering, unnecessary API requests, and memory leaks.

Use bounded performance testing against isolated environments.

Do not invent benchmark results.

---

# 11. DOCKER, INFRASTRUCTURE AND PRODUCTION CONFIGURATION

Audit deployment configuration and operational boundaries.

Check:

- Dockerfiles
- Docker Compose configuration
- Image version pinning
- Container user permissions
- Exposed ports
- Network isolation
- Volume mounts
- Filesystem permissions
- Secrets injection
- Health checks
- Restart policies
- Resource limits
- Reverse-proxy routing
- TLS and HTTPS
- Secure headers
- Internal service exposure
- Database connectivity
- Environment-variable validation
- Startup ordering
- Service dependencies
- Persistent storage

Inspect production-specific configuration separately from development configuration.

Ensure development-only services, debugging facilities, and test credentials cannot accidentally be exposed in production.

Check for configuration drift between the qualified environment and the intended release environment.

Do not change live infrastructure during assessment.

---

# 12. CI/CD AND BUILD REPRODUCIBILITY

Independently verify the release pipeline.

Require fresh evidence for:

- Dependency restoration
- Frontend linting
- Type checking
- Frontend unit tests
- Backend unit tests
- Integration tests
- MariaDB tests
- Browser/E2E tests
- Accessibility automation
- Security analysis
- Production builds
- Container builds
- Docker configuration validation
- PDF fidelity tests
- Deployment smoke tests

Assess hosted CI runner isolation and any previously blocked tests.

Validate that the release can be built reproducibly from a specific commit.

Record:

- Commit SHA
- Branch
- Build identifiers
- Environment
- Test commands
- Pass/fail counts
- Skipped tests
- Known exclusions
- Artifact identifiers
- Image digests when available

Never claim a gate passed based solely on an old test run.

Do not skip failing tests or weaken quality checks to obtain a green pipeline.

---

# 13. BACKUPS, RESTORE AND ROLLBACK

Verify that production data can be recovered.

Evaluate:

- Database backups
- File and attachment backups
- Persistent volumes
- Retention configuration
- Backup integrity
- Recovery access controls
- Restore instructions
- Recovery point objectives
- Recovery time objectives
- Deployment rollback
- Database migration compatibility
- Recovery after partial deployment failure

Perform an isolated restore test where possible.

Verify recovered data rather than merely checking backup-file existence.

Document the exact rollback procedure and any irreversible operations.

Never perform a production restore or destructive migration without explicit authorization.

A rollback that cannot restore data consistency is not a verified rollback.

---

# 14. OBSERVABILITY AND OPERATIONS

Check that operational failures can be detected and diagnosed.

Assess:

- Structured logging
- Correlation IDs
- Error reporting
- Health endpoints
- Readiness checks
- Service metrics
- Database monitoring
- Resource monitoring
- Background job failures
- Email integration errors
- AI provider errors
- Alerting
- Log retention
- Sensitive-data redaction

Ensure health checks reflect meaningful service readiness.

Identify missing operational runbooks.

Do not report monitoring as validated unless its signals and relevant failure behaviours have been tested.

---

# 15. DOCUMENTATION AND COMPLIANCE REVIEW

Review:

- Installation instructions
- Development setup
- Production deployment instructions
- Environment configuration
- User documentation
- Administrator documentation
- API documentation
- Release notes
- Support procedures
- Recovery runbooks
- Privacy and data-handling documentation
- Data export and deletion procedures

Flag legal and regulatory requirements needing specialist review rather than presenting an engineering audit as legal certification.

Ensure documentation reflects the actual implementation.

---

# 16. REMEDIATION WORKFLOW

When defects are discovered:

1. Record the defect and evidence.
2. Reproduce it reliably.
3. Determine severity and root cause.
4. Identify a focused solution.
5. Implement the fix on a dedicated branch where safe and authorized.
6. Add or update regression tests.
7. Re-run relevant tests.
8. Reassess security and accessibility impacts.
9. Record the resulting status.
10. Re-run broader acceptance gates when changes may affect other systems.

Prioritize:

**P0 — Critical**
Severe compromise, major data loss, or catastrophic production failure.

**P1 — High**
Exploitable significant vulnerabilities, broken critical workflows, or major reliability failures.

**P2 — Medium**
Meaningful defects with limited impact or reliable workarounds.

**P3 — Low**
Minor defects and cosmetic improvements.

Severity must reflect evidence and impact, not simply the type of finding.

Do not silently accept P0 or P1 issues.

P2 issues require explicit release-risk review and disposition.

P3 issues may be deferred with documented justification.

If remediation requires architectural changes or introduces significant data risk, present the plan and request approval before proceeding.

Avoid unrelated feature development.

---

# 17. RELEASE ACCEPTANCE MATRIX

Create a traceable acceptance matrix covering:

| Gate | Required verdict |
|---|---|
| Functional regression | PASS |
| Frontend and UX | PASS |
| Accessibility | PASS or documented limited scope pending decision |
| Authentication/authorization | PASS |
| Security assessment | PASS |
| Backend APIs | PASS |
| MariaDB and migrations | PASS |
| CV/PDF fidelity | PASS |
| AI integrations | PASS |
| Email/OAuth integrations | PASS |
| Performance and reliability | PASS |
| Docker/infrastructure | PASS |
| CI/CD qualification | PASS |
| Backup/restore | PASS |
| Deployment/rollback readiness | PASS |
| Operational monitoring | PASS |
| Documentation | PASS |
| Human/device/provider acceptance | PASS |

Use four gate states:

- PASS — Successfully verified with evidence.
- FAIL — Verified unacceptable behaviour or unmet requirement.
- BLOCKED — Cannot complete verification because of a dependency.
- NOT TESTED — No sufficient verification performed.

An accepted exception may be documented, but it must not be mislabeled PASS.

Apply the following release rules:

- Any critical security, data-integrity, or release-safety failure means NO-GO.
- Any unresolved mandatory gate means NO-GO.
- Any blocked mandatory gate means NO-GO.
- Missing production-equivalent verification cannot be treated as success.
- Risk acceptance requires explicit approval and documentation.
- A CONDITIONAL GO recommendation must identify exact remaining conditions; it is not permission to deploy.

The final release verdict must be based on completed, fresh evidence.

---

# 18. REQUIRED DELIVERABLES

Create:

`docs/release-readiness/`

Generate:

1. `01_SYSTEM_INVENTORY.md`
2. `02_RELEASE_BASELINE.md`
3. `03_FUNCTIONAL_TEST_REPORT.md`
4. `04_FRONTEND_UX_ACCESSIBILITY.md`
5. `05_SECURITY_ASSESSMENT.md`
6. `06_DATABASE_INTEGRITY.md`
7. `07_PDF_FIDELITY.md`
8. `08_PERFORMANCE_REPORT.md`
9. `09_INFRASTRUCTURE_AUDIT.md`
10. `10_CI_CD_QUALIFICATION.md`
11. `11_BACKUP_RESTORE_ROLLBACK.md`
12. `12_OPERATIONAL_READINESS.md`
13. `13_REMEDIATION_REGISTER.md`
14. `14_RELEASE_ACCEPTANCE_MATRIX.md`
15. `15_DEPLOYMENT_RUNBOOK.md`
16. `16_RELEASE_NOTES.md`
17. `17_FINAL_GO_NO_GO_REPORT.md`

Use consistent finding IDs across all reports.

Every result must distinguish verified facts, inferred risks, untested items, and recommendations.

Each report should include test evidence, relevant commands, environment details, and outcome summaries where applicable.

Do not fabricate test results, screenshots, CI results, or verification claims.

Avoid storing secrets or sensitive personal data in reports.

---

# 19. FINAL GO / NO-GO REPORT

Produce a concise executive report containing:

## Release candidate
- Branch
- Commit SHA
- Application version
- Build identifiers
- Container image identifiers
- Test environment
- Assessment date

## Overall decision
Choose exactly one:

**GO**
All mandatory gates passed, and release is ready for human deployment authorization.

**CONDITIONAL GO**
Remaining conditions are explicitly documented and must be satisfied before release.

**NO-GO**
One or more mandatory gates have failed, remain blocked, or lack required verification.

## Supporting evidence
Include:

- Test suite results
- Security findings
- Accessibility results
- Performance measurements
- Migration verification
- PDF fidelity qualification
- CI status
- Backup/restore results
- Deployment rehearsal results

## Outstanding risks
Identify every unresolved issue, its severity, and release impact.

## Required human actions
List any actions that cannot safely be completed automatically.

## Deployment recommendation
Explain the safest next release action and any remaining approval requirements.

Do not change the verdict to make the project appear more complete.

---

# 20. DEPLOYMENT APPROVAL BOUNDARY

Even if every acceptance gate passes:

**DO NOT DEPLOY AUTOMATICALLY.**

Do not:

- Merge into main/master
- Publish a production release
- Push deployment tags
- Replace running containers
- Apply production migrations
- Modify production secrets
- Change live DNS or proxy configuration
- Execute destructive production operations

without explicit authorization.

A GO verdict is a recommendation, not deployment permission.

Prepare the production deployment runbook and wait for my approval before carrying out release operations.

---

# 21. EXECUTION STRATEGY

Work systematically and avoid losing progress.

Use this execution order:

**Stage 1 — Discovery**
Inspect the repository, existing evidence, architecture, and outstanding blockers.

**Stage 2 — Baseline**
Capture fresh build and test results without changing implementation.

**Stage 3 — Qualification**
Run functional, security, accessibility, performance, database, PDF, and infrastructure assessments.

**Stage 4 — Remediation**
Fix reproducible issues on an isolated branch, prioritizing release blockers.

**Stage 5 — Requalification**
Retest fixes and run relevant full regression gates.

**Stage 6 — Release rehearsal**
Validate build reproducibility, migration procedures, deployment configuration, smoke tests, restore, and rollback in an authorized isolated environment.

**Stage 7 — Final acceptance**
Consolidate evidence and produce the GO / CONDITIONAL GO / NO-GO report.

At each stage:

- Keep documentation updated.
- Maintain a clear issue register.
- Record commands and results.
- Explain blockers.
- Keep changes focused.
- Preserve existing functionality.
- Avoid unsupported claims.
- Do not silently skip work.

Use existing project tests and installed security tooling where appropriate.

Do not substitute a large number of passing unit tests for missing end-to-end or production-equivalent verification.

If work is interrupted, preserve enough checkpoint information in the repository to resume accurately.

---

# 22. BEGIN NOW

Start by:

1. Inspecting the repository and its current branch.
2. Reading previous qualification and redesign documentation.
3. Revalidating historical release blockers.
4. Discovering the actual production architecture.
5. Running safe baseline checks.
6. Building the release acceptance matrix.
7. Identifying the highest-risk release gaps.
8. Preparing the initial remediation plan.

You may perform read-only checks and safe local tests without further approval.

Use a dedicated branch for authorized code fixes.

Do not run destructive tests or alter production resources without explicit permission.

Continue through the complete release-readiness workflow wherever the required tools, environments, and authorization permit.

Do not stop at a high-level checklist.

Perform actual checks, produce evidence, fix applicable issues, and verify the fixes.

If a gate cannot be completed, record exactly why rather than pretending it passed.

**Your ultimate objective is to produce a production-ready Jobbjakt release candidate backed by credible verification evidence, with no hidden critical risks, and a transparent GO / NO-GO decision.**