# Jobjakt — AUTOMATION-HANDOFF-01
## Finish Pre-Phase-10 Acceptance and Prepare for Autonomous Roadmap Execution

### Your role

Act as Jobjakt's senior QA engineer, release engineer, software architect, Git integration specialist and autonomous-development handoff coordinator.

Your task is to complete the remaining safely achievable Pre-Phase-10 acceptance work and prepare a reliable, machine-readable handoff for the separate AUTONOMOUS-ROADMAP-01 Codex orchestrator.

**Do not begin Phase 10.**

Your objective is to leave the development repository in a verified, clean, reproducible state from which an independently authorised automation system can safely begin Phase 10 and eventually continue through the remaining roadmap.

Work autonomously through normal development, testing, remediation, documentation and feature-branch publication.

Only interrupt me when genuine human approval, manual testing or external infrastructure action is needed.

---

# 1. Starting baseline

Latest reported development environment:

Local URL:
`http://jobbjakt.local/`

Branch:
`test/pre-phase10-ux-acceptance`

Latest reported commit:
`5032ccb`

Reported status:

- Working tree clean.
- Backend: 1,448 tests passed.
- Frontend: 1,031 tests passed.
- Python: 83 tests passed.
- Real MariaDB: 90 tests passed.
- Ordinary browser regression: 380 tests passed.
- Real CV extraction verified.
- Queued AI strategy generation verified.
- Scheduled job enrichment verified.
- Conflicting JSON instructions in the strategy route corrected.
- Synthetic accounts and temporary test containers cleaned up.
- Two local commits remain unpublished because Git server connectivity failed.
- Production remains NO-GO.
- No merge or deployment occurred.

Outstanding qualifications include:

- CV AI extraction and semantic accuracy.
- Human accessibility testing.
- Physical-device testing.
- Human language review.
- PDF template spacing and visual qualification.
- Historical Phase 9, Python dependency and CI requirements where still applicable.
- Existing production-only infrastructure and recovery gates.

Read the actual current evidence before relying on this summary.

Primary documentation:

`docs/pre-phase10-ux/ACCEPTANCE.md`

`docs/pre-phase10-ux/CV_QA_HANDOFF.md`

Also inspect the authoritative CV-UX, CV-IMPORT, CV-QA, RD21, Phase 9, Phase 10 and preservation documentation.

Verify which reported checks are actually complete, which were conditionally accepted and which remain outstanding.

Do not invent evidence for missing results.

---

# 2. Relationship to the automation orchestrator

A separate workstream named:

`AUTONOMOUS-ROADMAP-01`

is responsible for building a persistent Windows-compatible Codex orchestrator.

That orchestrator will eventually process the approved roadmap:

05 — Phase 10 cleanup.

06 — PRODUCT-REVIEW-01.

07 — INT-GLOBAL-JOBS-01.

08 — I18N-01 translations.

09 — LAUNCH-SITE-01 homepage redesign.

10 — SECURITY-AUDIT-01.

11 — RELEASE-READINESS-01.

Your responsibility is **not** to implement or run this orchestrator.

Your responsibility is to make the current repository and its acceptance evidence suitable for the orchestrator to consume.

You must provide:

- An authoritative accepted development baseline.
- A complete pre-Phase-10 blocker register.
- Structured acceptance evidence.
- Stage dependency and gate definitions.
- Explicit deferrals and reasons.
- Human approval requirements.
- Git branch and remote state.
- Reproducible verification commands.
- An exact Phase 10 handoff.

Coordinate through documented contracts, not by modifying the other worktree or running a second orchestrator.

---

# 3. Git and worktree safety

Stay on the currently authorised Pre-Phase-10 development branch, or the verified equivalent worktree containing its complete history.

Before making changes:

1. Verify Git status.
2. Verify current HEAD.
3. Verify ancestry of commit `5032ccb`.
4. Inspect pending local commits.
5. Identify the configured Gitea remote.
6. Confirm the worktree is not being modified by another Codex session.
7. Determine which branch contains the latest accepted integration history.

Do not assume `main` includes the redesign.

Do not reset, rebase destructively, cherry-pick blindly or force-push.

Do not alter the separate automation worktree.

Do not merge into `main`.

Do not deploy production.

If new commits are required, keep them on the authorised pre-Phase-10 branch and document their hashes.

---

# 4. P10-HANDOFF-00 — Comprehensive acceptance reconciliation

Begin with a complete review of the existing acceptance evidence.

Determine whether the currently reported implementation genuinely satisfies the mandatory development requirements.

Investigate:

### CV Builder

- Creating a completely blank CV with zero unwanted content sections.
- Creating a CV from Career Profile.
- Undo/redo across supported editor operations.
- Save, refresh and recovery.
- Multiple-session editing.
- Existing CV compatibility.
- Historical document preservation.

### CV templates

- Existing template spacing.
- New template library.
- Optional-photo templates.
- Font consistency.
- Page margins.
- Section spacing.
- Bullet indentation.
- Multi-page layout.
- PDF preview/export agreement.

### CV import

- Real PDF extraction.
- Real DOCX extraction.
- Career Profile mapping.
- New-record creation.
- Review and corrections.
- Duplicate handling.
- Transactional MariaDB persistence.
- Failure recovery.
- Source provenance.

### Dashboard

- Widget drag-and-drop.
- Resizing.
- Show/hide controls.
- Layout persistence.
- Mobile behaviour.
- Keyboard accessibility.
- Existing preference compatibility.

### Admin Processing Monitor

- Job attribution to the submitting user.
- Related job application or import record.
- Processing stage.
- Status and duration.
- Failure diagnostics.
- Sanitised event logs.
- Administrative authorisation.
- Tenant isolation.
- Log redaction.

### AI workflows

- CV extraction.
- Queued AI strategy generation.
- Scheduled job enrichment.
- Safe structured outputs.
- Processing failure handling.
- Disabled/unqualified AI functionality.
- Model compatibility and semantic qualification requirements.

### Application preservation

- Existing routes.
- Authentication.
- Career Profile.
- Jobs and applications.
- CVs.
- Cover letters.
- Dashboard.
- Settings.
- Administration.
- English/Norwegian.
- Existing functionality-preservation contracts.

Use actual repository implementation and evidence.

Create a traceability matrix mapping each required capability to its test evidence and acceptance status.

Do not claim that an untested feature passed merely because its implementation exists.

---

# 5. P10-HANDOFF-01 — Fix remaining bounded defects

Investigate the remaining pre-Phase-10 defects.

Prioritise:

1. User-data loss or corruption.
2. Broken Career Profile persistence.
3. Import approval failures.
4. Missing-record creation.
5. Undo/redo defects.
6. Incorrect blank CV behaviour.
7. Broken template spacing or clipping.
8. Missing PDF content.
9. Admin authorisation or sensitive-log exposure.
10. Broken dashboard persistence.
11. Confirmed regressions in existing workflows.

Fix reproducible defects that are within the current acceptance scope.

For each fix:

- Record the reproduction.
- Identify the root cause.
- Implement the smallest maintainable correction.
- Add regression tests.
- Run targeted verification.
- Update the acceptance matrix.

Do not begin unrelated product features.

Do not redesign major parts of Jobjakt unnecessarily.

If a requested change is genuinely outside the existing acceptance scope, record it as a separate backlog item rather than silently expanding Phase 10.

Do not change acceptance criteria solely to obtain a PASS.

---

# 6. P10-HANDOFF-02 — PDF spacing and document qualification

The remaining PDF spacing review requires particular attention.

The original PDF fidelity fixtures previously passed on Windows and Linux, but this does not automatically establish that every template has excellent spacing.

Perform a dedicated visual and functional audit of the current CV template library.

Render representative synthetic CVs using every available template.

Include:

- Short CV.
- Long CV.
- Multiple employers.
- Dense education.
- Long skill lists.
- Several languages.
- Norwegian characters.
- Optional profile photographs.
- Multi-page content.
- Cover letters where applicable.

Check:

- Section spacing.
- Line height.
- Paragraph rhythm.
- Headers.
- Margins.
- List indentation.
- Column alignment.
- Page breaks.
- Font weights.
- Text clipping.
- Missing content.
- Excessive whitespace.
- Preview/PDF differences.

Generate actual rendered preview images or PDFs for inspection.

Fix measurable formatting defects.

Create a visual comparison package for owner review where aesthetic approval is necessary.

Retain historical document compatibility and existing licensed-font arrangements.

Do not modify golden fixtures merely to conceal regressions.

Distinguish:

- Automated PDF fidelity: PASS/FAIL.
- Semantic content completeness: PASS/FAIL.
- Visual spacing qualification: PASS/PARTIAL/FAIL.
- Human print approval: PASS/NOT TESTED.

If human visual or printing acceptance is required by the authoritative Phase 10 entry criteria, prepare the relevant review artifacts and keep that gate pending until I approve them.

---

# 7. P10-HANDOFF-03 — Real AI and security qualification

Review the actual current AI architecture.

The latest report states real CV extraction, queued AI strategy generation and scheduled enrichment have been verified.

Determine precisely what was exercised.

Distinguish:

- Real Docling parsing.
- Deterministic extraction.
- Model-assisted processing.
- Queued task execution.
- Structured-output validation.
- Real model inference.
- Semantic correctness.
- User-reviewed final output.
- Source-grounded accuracy.

Do not interpret a successful AI request or completed background job as proof of good AI output.

Inspect the existing model qualification and Python dependency security evidence.

Determine which checks can safely run in the isolated development environment.

If approved model artifacts and safe runtime conditions exist, conduct authorised targeted model evaluations.

Otherwise preserve the relevant qualification as BLOCKED or NOT TESTED.

Do not download large models to production.

Do not change live Ollama services or model caches.

Do not accept security risks on my behalf.

If optional AI functionality is disabled, isolated and not required for Phase 10 code cleanup, document whether its remaining qualification can legally and technically be deferred under the existing acceptance criteria.

Do not falsely mark AI production-ready.

---

# 8. P10-HANDOFF-04 — Human and manual acceptance

Prepare a prioritised owner-test package.

Include:

- What to test.
- Why it matters.
- Exact page or workflow.
- Preconditions.
- Test steps.
- Expected behaviour.
- Pass/fail criteria.
- Evidence to capture.
- Whether the test blocks Phase 10 or production only.

Cover:

- Real mobile/tablet.
- Keyboard-only usage.
- Screen reader.
- English copy.
- Norwegian Bokmål copy.
- Other implemented languages.
- CV editor usability.
- Template visual approval.
- PDF printing.
- Job tracking.
- Dashboard layout.
- Admin diagnostics.
- AI-generated content review where enabled.

Complete checks that can genuinely be performed automatically.

Do not fabricate physical-device, human language, screen-reader or printing test results.

Where a mandatory human decision is needed, flag it clearly.

Prefer a small, well-prioritised owner checklist over a large unstructured testing document.

---

# 9. P10-HANDOFF-05 — Resolve Git publication

Two local commits were reported to be awaiting publication.

Diagnose the Gitea connectivity issue safely.

Verify:

- Remote URL.
- DNS.
- Network reachability.
- HTTPS connectivity.
- TLS validation.
- Git authentication, if reached.
- Local/remote branch divergence.

If the remote becomes available, perform a normal push of the authorised development branch.

Verify remote HEAD equals the intended local commit.

Do not force-push.

Do not disable TLS verification.

Do not expose tokens or credentials.

If connectivity remains unavailable:

- Preserve all local commits.
- Record precise diagnostics.
- Mark Git publication BLOCKED.
- Provide exact operator actions.
- Do not declare the remote branch published.

A pending or failed push must be represented accurately in the automation handoff.

Do not let the orchestrator silently assume that a local commit exists remotely.

Also inspect the separately completed GJ-00 planning branch's publication status without merging or modifying it.

---

# 10. P10-HANDOFF-06 — Full regression baseline

After bounded remediation, run the applicable regression suites.

Include:

- .NET backend.
- React frontend.
- Ordinary browser.
- CV import browser journeys.
- Real MariaDB integration.
- RD21 concurrency and recovery.
- Python sidecar.
- Document extraction.
- Queued processing.
- Scheduled job enrichment.
- CV Editor.
- PDF fidelity.
- Dashboard customisation.
- Admin processing monitor.
- Browser contracts.
- TypeScript.
- Lint.
- Builds.
- Security scans.
- Existing functionality preservation.

Use approved isolated environments.

Record:

- Commands.
- Exit codes.
- Environment details.
- Passed/failed/skipped counts.
- Test report paths.
- Final commit.
- Relevant test artifacts.
- Any checks not run.

Do not treat previously reported counts as newly executed evidence.

Never weaken tests merely to achieve a green result.

Ensure generated test reports are attributable to the specific tested commit.

---

# 11. P10-HANDOFF-07 — Define precise Phase 10 entry gates

This is the most important orchestration requirement.

Review the authoritative Phase 10 entry criteria.

Separate all outstanding work into:

### A. Mandatory Phase 10 blockers

Issues that must be resolved before code cleanup can safely begin.

### B. Permissible conditional-development deferrals

Items that may remain outstanding during Phase 10 only where an existing approved acceptance rule permits it.

### C. Production release blockers

Issues that can be addressed later without invalidating Phase 10 development.

### D. Future feature work

Items belonging to the post-Phase-10 product roadmap.

For every item include:

- Stable ID.
- Description.
- Evidence.
- Severity.
- Relevant acceptance criterion.
- Required action.
- Blocking phase.
- Responsible party.
- Deferral authority, if any.
- Current status.

Do not infer that an item is deferrable simply because it is inconvenient.

If a requirement is ambiguous or a conditional entry needs owner judgement, request approval rather than inventing permission.

Do not require every production-only infrastructure issue to be resolved before non-production Phase 10 work unless the authoritative criteria actually require it.

Likewise, do not advance with unresolved mandatory development-entry blockers.

---

# 12. P10-HANDOFF-08 — Machine-readable orchestration contract

Produce structured artifacts for the AUTONOMOUS-ROADMAP-01 orchestrator.

Place handoff documentation under:

`docs/automation/handoffs/pre-phase10/`

Use repository conventions where appropriate.

Required artifacts:

### `HANDOFF.md`

Human-readable overview of the current accepted state and readiness.

### `ACCEPTANCE.json`

Machine-readable status.

Include:

- Schema version.
- Workstream ID.
- Source branch.
- Local commit.
- Verified remote commit, if available.
- Worktree cleanliness.
- Acceptance status.
- Entry-gate status.
- Test evidence references.
- Unresolved blocker IDs.
- Permissible deferrals.
- Required owner approvals.
- Generation timestamp.
- Recommendation for Phase 10.

### `GATES.json`

Define stage-specific gate requirements, including:

- Required predecessor.
- Required test suites.
- Minimum acceptable evidence.
- Required Git state.
- Required preservation checks.
- Required manual approvals.
- Permissible conditional deferrals.
- Blocking findings.

### `BLOCKERS.json`

Structured unresolved-issue register.

### `TEST_EVIDENCE.json`

Index machine-verifiable test results and report artifacts.

Include commit binding and actual process exit codes.

### `MANUAL_ACCEPTANCE.md`

Prioritised human test and approval checklist.

### `PHASE10_BASELINE.md`

Exact branch and commit ancestry, preservation scope, safe cleanup targets and required compatibility checks.

### `READY_TO_RUN.md`

Exact conditions required to start automated Phase 10.

### `HANDOFF_SCHEMA.json`

JSON Schema for the exported acceptance package.

Validate all structured JSON.

Use stable keys and explicit status enums.

Do not include secrets, personal data or machine-specific credentials.

Absolute local paths may be included as informational references, but prefer repository-relative paths for portable automation.

---

# 13. Critical acceptance-security rule

The handoff package is evidence, not authority by itself.

A Codex-generated `ACCEPTANCE.json` must not be able to bypass a gate simply by claiming:

`"status": "GO"`

The orchestrator must independently verify:

- Required report existence.
- Test exit codes.
- Commit correspondence.
- Remote publication.
- Accepted predecessor stages.
- Mandatory blocker status.
- Applicable owner approvals.

Owner approvals must be maintained outside the model-writable repository or through another protected approval mechanism.

Do not generate approval tokens or owner signatures.

Do not mark human acceptance PASS without actual approval evidence.

If the external orchestrator already defines an acceptance schema, conform to it where compatible rather than creating a conflicting parallel standard.

If it is still under development, produce a clearly versioned proposed contract and document the integration requirements.

---

# 14. P10-HANDOFF-09 — Phase 10 cleanup inventory

Prepare the scope for the actual Phase 10 task.

Identify proven superseded components and code.

Include:

- Legacy CV Editor components.
- Old CV import components.
- Replaced dashboard layout configuration.
- Superseded admin-processing views.
- Unused style utilities.
- Duplicate services.
- Unreferenced frontend routes.
- Obsolete feature flags.
- Potentially unused dependencies.
- Historical compatibility components that must remain.
- Database code with active compatibility requirements.

For every proposed removal include:

- Location.
- Why it appears obsolete.
- Evidence of actual replacement.
- Current consumers.
- Dynamic/runtime reference risks.
- Related preservation group.
- Required regression test.
- Removal risk.

Do not remove these items as part of the handoff.

Do not delete old PDF renderers, document mappings or migrations solely because newer implementations exist.

Do not retire SQLite automatically.

Do not perform MariaDB major-version upgrades.

Phase 10 will make removal decisions using this evidence.

---

# 15. P10-HANDOFF-10 — Reconcile the remaining roadmap

The automation queue after Phase 10 is intended to contain:

05 — Phase 10 final redesign cleanup.

06 — PRODUCT-REVIEW-01 full application review.

07 — INT-GLOBAL-JOBS-01 international, cross-industry job discovery.

08 — I18N-01 expanded translations and locale qualification.

09 — LAUNCH-SITE-01 multilingual homepage redesign.

10 — SECURITY-AUDIT-01 adversarial audit and remediation.

11 — RELEASE-READINESS-01 production qualification.

Also preserve separate tracked initiatives:

- Deferred P5-13 AI qualification and model assessment.
- LinkedIn integration feasibility.
- Android application.
- SQLite retirement.
- MariaDB upgrade strategy.
- Monitoring and operational improvements.
- Future country integrations.

These initiatives must not be silently discarded simply because they aren't numbered 05–11.

Highlight the dependencies:

- Global Job Search depends on approved planning and provider permissions.
- Internationalisation overlaps with Global Job Search and homepage work.
- Product Review requires owner approval before starting its resulting implementation scope.
- Homepage final visual design requires owner approval.
- Production requires independent security, backup, recovery and release approval.

Create an automation-friendly roadmap summary without starting any later workstream.

---

# 16. Autonomous execution checkpoints

Execute safely in this order:

### AUTO-H01 — Baseline and acceptance reconciliation
Read the reports, verify actual Git state and establish existing evidence.

### AUTO-H02 — Targeted defect remediation
Fix bounded confirmed pre-Phase-10 defects.

### AUTO-H03 — PDF and AI qualification
Complete permitted verification and document remaining blocked items.

### AUTO-H04 — Manual acceptance preparation
Produce focused human test packages and record genuine approvals.

### AUTO-H05 — Git publication recovery
Publish pending development commits if the remote is available.

### AUTO-H06 — Full regression
Establish commit-bound verification evidence.

### AUTO-H07 — Structured automation handoff
Produce and validate schemas, gates, blocker registers and evidence manifests.

### AUTO-H08 — Phase 10 readiness
Determine the actual acceptance decision and exact automation prerequisites.

Commit and push validated checkpoints.

If the remote is unavailable, continue safe independent work and preserve commits locally.

Do not claim remote publication when it is unverified.

---

# 17. Required final decisions

Issue independent verdicts for:

**Pre-Phase-10 UX:** GO / CONDITIONAL GO / NO-GO.

**CV Integration:** GO / CONDITIONAL GO / NO-GO.

**PDF Spacing:** PASS / PARTIAL / FAIL.

**CV AI Accuracy:** PASS / PARTIAL / BLOCKED.

**Human/Device Acceptance:** PASS / PARTIAL / NOT TESTED.

**Python Security:** PASS / CONDITIONAL / BLOCKED.

**Hosted CI:** PASS / BLOCKED / FAIL.

**Preservation:** PASS / PARTIAL / FAIL.

**Git Publication:** VERIFIED / BLOCKED.

**Phase 10 Development Readiness:** GO / CONDITIONAL GO / NO-GO.

**Automation Handoff Package:** READY / INCOMPLETE.

**Production:** GO / NO-GO.

Every verdict must cite actual supporting evidence.

Distinguish implementation completion from acceptance, deployment and release readiness.

---

# 18. Final report

At completion, report:

1. Current branch and final commit.
2. Working-tree status.
3. Remote publication state.
4. Defects fixed.
5. Tests executed and actual totals.
6. Outstanding mandatory blockers.
7. Permitted deferrals.
8. Human actions required.
9. Automation handoff artifacts created.
10. Acceptance schema validation result.
11. Phase 10 entry decision.
12. Exact integration baseline for the orchestrator.
13. Whether the orchestrator may start automatically.
14. What it must verify independently before doing so.

If Phase 10 receives an authoritative GO or approved CONDITIONAL GO, mark the handoff eligible for orchestration.

However, **do not actually begin Phase 10**.

If required conditions remain outstanding, mark the stage BLOCKED and state exactly how it can become READY.

---

# 19. Hard restrictions

Do not:

- Merge into `main`.
- Deploy production.
- Start Phase 10.
- Start Global Job Search.
- Start the Product Review.
- Modify the separate automation worktree.
- Fabricate owner approval.
- Self-approve acceptance exceptions.
- Bypass Python security qualifications.
- Modify live Ollama.
- Download unapproved production models.
- Change production MariaDB.
- Perform destructive database migrations.
- Modify production Docker services.
- Modify or repair production filesystems.
- Remove compatibility code prematurely.
- Lower test requirements to achieve a GO.

Do not introduce unnecessary changes that disrupt the locally running `jobbjakt.local` environment.

If a test requires destructive operations, use a disposable database or isolated test environment.

---

# FINAL INSTRUCTION

Starting from the real current Pre-Phase-10 acceptance state, complete all safely achievable outstanding acceptance and remediation work.

Restore Git publication where possible.

Prepare a **machine-readable, independently verifiable Phase 10 handoff** suitable for AUTONOMOUS-ROADMAP-01.

Make the handoff robust enough that the orchestrator can identify:

- What has passed.
- What is blocked.
- What may be deferred.
- Which human approvals are required.
- Which exact commit forms the accepted baseline.
- Whether Phase 10 may begin.

Work autonomously, commit and push validated checkpoints, and prepare all necessary documentation.

**STOP after the final handoff report. Do not start Phase 10, merge into main or deploy production.**