cesnimda
201 lines
5.2 KiB
Markdown
201 lines
5.2 KiB
Markdown
# Jobjakt — P10-ENTRY-FINAL
|
|
## Resolve Remaining PDF Acceptance and Prepare Final Phase 10 Approval
|
|
|
|
The Pre-Phase-10 automation handoff is complete and published.
|
|
|
|
Branch:
|
|
`test/pre-phase10-ux-acceptance`
|
|
|
|
Accepted handoff candidate:
|
|
`26d531cc9079be3be7601f42cb101035de022a4d`
|
|
|
|
Remote publication is verified.
|
|
|
|
The handoff package is READY, but Phase 10 remains NO-GO.
|
|
|
|
Your task is to resolve the remaining safely actionable Phase 10 entry blockers, beginning with PDF spacing qualification.
|
|
|
|
## 1. Read the authoritative evidence
|
|
|
|
Inspect:
|
|
|
|
- `docs/automation/handoffs/pre-phase10/HANDOFF.md`
|
|
- `docs/automation/handoffs/pre-phase10/READY_TO_RUN.md`
|
|
- `docs/automation/handoffs/pre-phase10/MANUAL_ACCEPTANCE.md`
|
|
- Existing PDF fidelity and visual reports.
|
|
- Current CV template implementations.
|
|
- Phase 10 entry requirements.
|
|
- Previous preservation and regression evidence.
|
|
|
|
Do not assume the handoff's READY status authorises Phase 10.
|
|
|
|
## 2. Investigate PDF failures
|
|
|
|
The original PDF corpus passes.
|
|
|
|
The revised templates still exhibit:
|
|
|
|
- 28 Windows S01 failures.
|
|
- 20 Linux S01 failures.
|
|
|
|
Content completeness and full-height sidebar checks pass separately.
|
|
|
|
Determine exactly why the S01 checks fail.
|
|
|
|
Classify each failure as:
|
|
|
|
- Actual rendering defect.
|
|
- Spacing or pagination regression.
|
|
- Font or platform-specific rendering issue.
|
|
- Historical reference incompatibility.
|
|
- Incorrect test assumption.
|
|
- Other verified cause.
|
|
|
|
Do not assume that every failure is cosmetic.
|
|
|
|
Inspect actual rendered PDF output.
|
|
|
|
Investigate differences between Windows and Linux.
|
|
|
|
Preserve original document and historical compatibility requirements.
|
|
|
|
## 3. Remediate confirmed defects
|
|
|
|
Fix genuine spacing, clipping, alignment, pagination, typography and layout defects.
|
|
|
|
Prioritise:
|
|
|
|
- Consistent section spacing.
|
|
- Paragraph rhythm.
|
|
- Column alignment.
|
|
- Header spacing.
|
|
- Page boundaries.
|
|
- Bullet alignment.
|
|
- Sidebar layout.
|
|
- Photo positioning.
|
|
- Multi-page behaviour.
|
|
- Font consistency.
|
|
- PDF versus preview fidelity.
|
|
|
|
Do not simply regenerate golden files to make failing tests pass.
|
|
|
|
If a historical reference is demonstrably incompatible with an approved redesign, document that conflict and request explicit owner approval for any reference change.
|
|
|
|
## 4. Generate visual evidence
|
|
|
|
Produce an updated representative PDF review package covering every affected template.
|
|
|
|
Include:
|
|
|
|
- Short CV.
|
|
- Long CV.
|
|
- Dense CV.
|
|
- Multi-page CV.
|
|
- Norwegian characters.
|
|
- Relevant European characters.
|
|
- Optional user photo.
|
|
- Sidebar templates.
|
|
- Original templates.
|
|
- Revised templates.
|
|
|
|
Include before/after examples for confirmed fixes.
|
|
|
|
Use synthetic data.
|
|
|
|
Provide a concise owner review guide explaining which samples require my visual approval.
|
|
|
|
## 5. Run verification
|
|
|
|
Run affected PDF suites on Windows and Linux.
|
|
|
|
Run required preservation tests.
|
|
|
|
Verify:
|
|
|
|
- Content completeness.
|
|
- All original corpus checks.
|
|
- Revised template spacing.
|
|
- Cross-platform rendering.
|
|
- Preview/export consistency.
|
|
- Historical CV compatibility.
|
|
|
|
Rerun relevant frontend, backend and browser regressions.
|
|
|
|
Record actual counts, exit codes and artifact paths.
|
|
|
|
## 6. Reconcile the remaining blockers
|
|
|
|
Once PDF remediation is complete, reassess the Phase 10 entry decision.
|
|
|
|
Specifically distinguish:
|
|
|
|
A. Mandatory entry blockers.
|
|
|
|
B. Conditions eligible for explicit owner-approved deferral.
|
|
|
|
C. Production-only blockers.
|
|
|
|
D. Future work.
|
|
|
|
Assess the rejected CV-model probes separately.
|
|
|
|
Do not mark real AI compatibility or accuracy PASS without genuine evidence.
|
|
|
|
Do not automatically activate models or modify production Ollama.
|
|
|
|
Maintain accurate status for hosted CI, Python security, human/device acceptance and infrastructure recovery.
|
|
|
|
## 7. Prepare owner approval
|
|
|
|
Produce a short, prioritised checklist for the remaining tests that I personally need to perform.
|
|
|
|
Include exact actions, expected results and evidence required.
|
|
|
|
Identify whether each action blocks Phase 10 or production only, according to existing acceptance rules.
|
|
|
|
Do not manufacture human approval.
|
|
|
|
## 8. Update automation handoff
|
|
|
|
Update the structured handoff package with new commit-bound evidence.
|
|
|
|
Revalidate its JSON schemas and checks.
|
|
|
|
Produce an exact Phase 10 entry proposal containing:
|
|
|
|
- Candidate commit SHA.
|
|
- Accepted branch.
|
|
- Cleanup scope.
|
|
- Outstanding blockers.
|
|
- Explicit deferral requests.
|
|
- Required approval decisions.
|
|
- Test evidence.
|
|
- Verified Git publication state.
|
|
|
|
Do not self-approve entry.
|
|
|
|
## 9. Git safety
|
|
|
|
Keep changes on an authorised development branch.
|
|
|
|
Commit and push validated work.
|
|
|
|
Verify remote HEAD.
|
|
|
|
Do not modify the separate automation controller worktree.
|
|
|
|
Do not merge into main.
|
|
|
|
Do not deploy production.
|
|
|
|
## Final instruction
|
|
|
|
Complete the remaining PDF remediation and independently verifiable development-entry checks.
|
|
|
|
Provide genuine visual evidence for owner approval.
|
|
|
|
Update the machine-readable Phase 10 handoff.
|
|
|
|
If all mandatory gates pass, prepare the exact owner approval request.
|
|
|
|
**STOP before beginning Phase 10 or executing the autonomous roadmap.** |