--- id: T02 parent: S06 milestone: M001 provides: [] requires: [] affects: [] key_files: ["scripts/s06-acceptance-data.sh", "scripts/s06-acceptance-data.test.sh", "README.md", ".gsd/KNOWLEDGE.md", ".gsd/DECISIONS.md", ".gsd/milestones/M001/slices/S06/tasks/T02-SUMMARY.md"] key_decisions: ["Seed acceptance data only through the live companies/jobapplications/correspondence API plus the dedicated tailored-cv, application-drafts, and followup endpoints, keyed by deterministic company/title/thread/message identifiers so reruns stay idempotent.", "Backdate both the seeded follow-up date and the latest correspondence timestamp past the active follow-up threshold so the acceptance fixture lands in workflowSignal.actionKey=follow-up instead of review-readiness."] patterns_established: [] drill_down_paths: [] observability_surfaces: [] duration: "" verification_result: "Ran bash scripts/s06-acceptance-data.test.sh against the live API with a valid dev-signed bearer token to confirm missing-token, bad-token, and double-rerun behavior. Ran bash scripts/s06-acceptance-data.sh against the real backend and confirmed seed.result=success, a stable company/job fixture, one correspondence entry, seed.workflow.action=follow-up, seed.readiness.level=Ready, and seed.reminders=Waiting 14d. Verified README.md contains the acceptance-data runbook markers and token guidance." completed_at: 2026-03-27T08:09:46.052Z blocker_discovered: false --- # T02: Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output. > Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output. ## What Happened --- id: T02 parent: S06 milestone: M001 key_files: - scripts/s06-acceptance-data.sh - scripts/s06-acceptance-data.test.sh - README.md - .gsd/KNOWLEDGE.md - .gsd/DECISIONS.md - .gsd/milestones/M001/slices/S06/tasks/T02-SUMMARY.md key_decisions: - Seed acceptance data only through the live companies/jobapplications/correspondence API plus the dedicated tailored-cv, application-drafts, and followup endpoints, keyed by deterministic company/title/thread/message identifiers so reruns stay idempotent. - Backdate both the seeded follow-up date and the latest correspondence timestamp past the active follow-up threshold so the acceptance fixture lands in workflowSignal.actionKey=follow-up instead of review-readiness. duration: "" verification_result: passed completed_at: 2026-03-27T08:09:46.053Z blocker_discovered: false --- # T02: Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output. **Seeded acceptance-ready job data through the live API with deterministic rerun-safe ids and readiness output.** ## What Happened Implemented scripts/s06-acceptance-data.sh as an executable live seed flow that requires AUTH_TOKEN, runs the existing S06 preflight first, then creates or reuses a deterministic acceptance company and job via the real API, updates recruiter metadata, saves tailored CV and application package material through the dedicated endpoints, schedules an overdue follow-up, and maintains exactly one deterministic correspondence entry for the linked recruiter thread. Added scripts/s06-acceptance-data.test.sh to verify the missing-token and bad-token failure modes plus authenticated idempotent reruns, updated README.md with the seed command and token guidance, recorded the waiting-threshold gotcha in .gsd/KNOWLEDGE.md, and saved D013 in .gsd/DECISIONS.md for the live-API seeding pattern. After correcting the seeded activity dates to cross the real 14-day RulesEngine threshold, the live fixture now reports workflowSignal.actionKey=follow-up and Waiting 14d reminder output. ## Verification Ran bash scripts/s06-acceptance-data.test.sh against the live API with a valid dev-signed bearer token to confirm missing-token, bad-token, and double-rerun behavior. Ran bash scripts/s06-acceptance-data.sh against the real backend and confirmed seed.result=success, a stable company/job fixture, one correspondence entry, seed.workflow.action=follow-up, seed.readiness.level=Ready, and seed.reminders=Waiting 14d. Verified README.md contains the acceptance-data runbook markers and token guidance. ## Verification Evidence | # | Command | Exit Code | Verdict | Duration | |---|---------|-----------|---------|----------| | 1 | `bash scripts/s06-acceptance-data.test.sh` | 0 | ✅ pass | 3885ms | | 2 | `bash scripts/s06-acceptance-data.sh` | 0 | ✅ pass | 1831ms | | 3 | `python3 README acceptance-data guidance check` | 0 | ✅ pass | 24ms | ## Deviations Added scripts/s06-acceptance-data.test.sh and recorded one knowledge/decision entry beyond the plan’s expected output files so the negative-path and idempotence contract is executable and the follow-up-threshold gotcha is preserved for downstream work. ## Known Issues The local seeded admin password from JobTrackerApi/appsettings.Development.json does not authenticate against this current DB snapshot, so the README and script comments document token retrieval in terms of the real local account or an already-authenticated browser session. Verification used a valid dev-signed JWT against the live API contract, which is sufficient for these user-scoped endpoints but does not prove the placeholder login credentials themselves. ## Files Created/Modified - `scripts/s06-acceptance-data.sh` - `scripts/s06-acceptance-data.test.sh` - `README.md` - `.gsd/KNOWLEDGE.md` - `.gsd/DECISIONS.md` - `.gsd/milestones/M001/slices/S06/tasks/T02-SUMMARY.md` ## Deviations Added scripts/s06-acceptance-data.test.sh and recorded one knowledge/decision entry beyond the plan’s expected output files so the negative-path and idempotence contract is executable and the follow-up-threshold gotcha is preserved for downstream work. ## Known Issues The local seeded admin password from JobTrackerApi/appsettings.Development.json does not authenticate against this current DB snapshot, so the README and script comments document token retrieval in terms of the real local account or an already-authenticated browser session. Verification used a valid dev-signed JWT against the live API contract, which is sufficient for these user-scoped endpoints but does not prove the placeholder login credentials themselves.