Janady13/missionmatch / docs/DIRECTIVE_AMENDMENTS_CONSOLIDATED.md

1# DIRECTIVE AMENDMENTS 1 THROUGH 5, CONSOLIDATED 2 3Companion to docs/CLAUDE_CODE_BUILD_DIRECTIVE.md. Generated 27 July 2026. 4This file supersedes the five individual amendment files. Conflicts are 5pre resolved: Amendment 3's corrections are already applied inside the 6Amendment 2 content below. There is nothing to reconcile. Apply this file 7and the directive together as the complete work order. 8 9-------------------------------------------------------------------------------- 100. AUTONOMOUS APPLICATION PROTOCOL 11-------------------------------------------------------------------------------- 12 131. Read order: CLAUDE.md, docs/CLAUDE_CODE_BUILD_DIRECTIVE.md, this file, 14 docs/BUILD_STATE.md. Then apply. 152. Record "amendments 1 through 5 accepted, consolidated" in BUILD_STATE 16 with the date and this file's path. 173. If individual amendment files exist under docs, move them to 18 docs/archive. Exactly one amendment source may exist: this file. 194. Merge map: Amendment 1 appends to directive Section 0 as an 20 environment rule. The slate approval lifecycle merges into Phase 3 21 and Gate 3. Desk integration, publishing, the Import Center, the 22 Candidates page, and the desk dataflow merge into Phase 5 and Gate 5. 23 The canonical dataflow becomes a permanent directive appendix. 24 Acceptance items 25 through 35 append to directive Section 11. Task 25 T1 registers as standalone work outside the phase gates. 265. Passed gates are never reopened. If an item conflicts with work 27 already completed, record the conflict in BUILD_STATE, choose the 28 smallest change that satisfies both, and note it. If no such change 29 exists, stop and surface it. 306. Autonomous operation: proceed phase by phase without waiting for 31 permission. Verify every gate against staging, record evidence in the 32 ledger, and continue. Surface to Joseph only for these four things: 33 any Phase 0 human blocker not yet recorded in the ledger, the vhost 34 confirmation for Task T1 if the target is ambiguous, review of the 35 two nginx location blocks before anything touches the live 36 fg-talent.com vhost, and the Gate 6 production cutover. 377. Every directive rule stands unchanged: staging only until Gate 6, 38 meaning missionmatch_staging on M4 port 5432 (see the corrected 39 location note directly below); the candidate 40 scoring engine is frozen; forced RLS and organization_id on every 41 tenant table; extend, never build beside; fail closed; no Python; no 42 dashes in written output, hyphens only in code identifiers, protocol 43 headers, and official designations. 44 45-------------------------------------------------------------------------------- 46AMENDMENT 1: ENVIRONMENT RULE 47-------------------------------------------------------------------------------- 48 49CORRECTED LOCATION, ratified by Joseph 28 July 2026. This file originally 50named staging as missionmatch_staging on megamind-agi port 5433. That 51database exists but is an EMPTY SHELL: zero organizations, zero 52candidates, and a goose_db_version table the app role cannot even read. 53IT MUST NOT BE USED. The functioning staging, and the only one this 54directive means, is: 55 56 missionmatch_staging on M4, 100.94.8.94, port 5432 57 58That is the database the live mm-api-staging service on 127.0.0.1:8097 59serves, it carries real working data, and it is the only staging target 60that can satisfy a gate, because a gate requires an end to end check 61through a live authenticated API and a rendered screen. 62 63Every migration, every live database verification, and every end to end 64check through Phase 5 runs against missionmatch_staging on M4 port 5432. 65The production tenant database is touched only at Gate 6, and only after 66the backup and restore test passes. If any task appears to require 67production before Gate 6, stop and record the conflict in BUILD_STATE 68instead of proceeding. 69 70The three Phase 0 human blockers, revoking the exposed OpenAI key, 71placing the fresh project scoped key on M4 as openai_api_key root owned 720600, and starting the SAM.gov system account application, were recorded 73as ledger events when Joseph completed them. If any of the three is 74absent from the ledger, do not enable anything external and surface it. 75 76-------------------------------------------------------------------------------- 77AMENDMENT 2, AS CORRECTED BY AMENDMENT 3: 78WORKFLOW COMPLETION AND PUBLIC SURFACES 79-------------------------------------------------------------------------------- 80 812.1 DECISIONS RECORDED 82 831. Slate approval becomes a lifecycle: proposed, approved, withdrawn. 84 Approval writes into proposal staffing links and readiness. 85 Withdrawal exists, requires a reason, and is fully audited. Amends 86 Phase 3. 872. screenMATCH and resumes wire into the recruiting desk through the 88 shared candidate record and a requisition to requirement bridge. The 89 frozen engine is reused through that bridge, never duplicated. Amends 90 Phase 5. 913. The primary public jobs surface is the tenant company's own website. 92 fg-talent.com is the first and the reference implementation. For a 93 mapped tenant, candidates never see the missionMATCH domain. 944. Serving pattern: nginx on Bubbles proxies fg-talent.com/careers/ to 95 the mm_api public jobs handler, which renders complete server side 96 HTML from Go templates, branded for the tenant. Crawlers and 97 visitors receive real HTML in the initial response. No client side 98 rendering of job content anywhere. This is chosen over static file 99 generation because it serves the same real HTML while updating the 100 instant a recruiter publishes or fills an order, one rendering path 101 instead of two. 1025. Tenant site mapping, configuration not code: tenant_slug, 103 public_base_url (https://fg-talent.com/careers), brand template, 104 consent notice reference. A mapped tenant's jobs path on the 105 missionMATCH domain issues a 301 to the tenant domain. Unmapped 106 tenants may use the app domain hosted jobs page. 1076. Apply is same origin on the tenant domain. fg-talent.com/careers/apply 108 proxies to the mm_api apply intake. A submission creates or dedupe 109 matches a candidate and creates an application in the applied stage 110 in the FG Talent tenant, source career_site, consent event stored 111 with notice version, honeypot plus an nginx limit_req zone on the 112 apply path modeled on the existing mm_auth zone. 1137. Nothing is ever posted to Google. Indexing follows the house SEO 114 rules and nothing else: a careers sitemap section regenerated on 115 every publish and unpublish, internal links from the careers index 116 and site navigation, GSC Request Indexing, and the URL Inspection 117 API. JobPosting JSON-LD remains on each job detail page as standard 118 on page schema, one block per canonical URL, mirroring the visible 119 content, because it makes the fg-talent.com pages themselves surface 120 in search and answer engines. That is the entire role Google plays. 1218. Expiry discipline: on fill, close, or validThrough passing, the page 122 unpublishes, the sitemap entry drops, and the markup is gone, 123 enforced by cmd/jobs-expiry-sweep, idempotent like everything else. 1249. FG Talent content rule, enforced in template and in test: only 125 Patricia Cox and Brian Atwood may appear anywhere on the public site 126 or in schema. Tom and Glennette are excluded from every page, every 127 JSON-LD block, every hiringOrganization contact, and every authored 128 by field. hiringOrganization is FG Talent Partners. 12910. Public surface hygiene: published fields only, never bill rates, 130 margins, internal notes, or client names without the per requisition 131 flag; tenant resolved by slug only, never by organization id; 132 unknown slug returns 404 with nothing leaked; zero EEO adjacency on 133 any public surface. 13411. The marketing site login button is standalone Task T1, executed on 135 the Bubbles vhosts, outside the phase gates and outside the 136 missionMATCH repo. 13712. The client portal read surface is deferred to fast follow, but its 138 data model, client submittals with feedback and reason codes, ships 139 now in Phase 5, so the portal later is a rendering task, not a 140 migration. 14113. Pay range fields on publish are optional, but the publish screen 142 warns when the posting location or remote eligibility touches a 143 state requiring a range in the posting: California, Colorado, 144 Hawaii, Illinois, Maryland, Massachusetts, Minnesota, New Jersey, 145 New York, Vermont, Washington, and the District of Columbia. 14614. Automated candidate outreach on status changes is deferred to fast 147 follow. Status changes create alerts and draft notifications a human 148 sends. Deterministic triggers only. 149 1502.2 TASK T1: MARKETING SITE LOGIN BUTTON 151 1521. Enumerate the nginx vhosts on Bubbles and identify where missionMATCH 153 is marketed publicly. The application lives at 154 https://missionmatch.thatwebhostingguy.com, so the button belongs on 155 the marketing surface, not inside the app. 1562. If the target is ambiguous, list the candidate vhosts for Joseph in 157 one message and wait for his pick. Do not guess on a production 158 website. 1593. Add a prominent Log in button in the site header and hero linking to 160 https://missionmatch.thatwebhostingguy.com. Static HTML, CSS, and 161 vanilla JS, brand consistent, no framework, no Python. 1624. If no marketing page exists, say so and build a single branded page, 163 hero, product line summary, and Log in, at the vhost Joseph names. 1645. Verify rendered in a browser over HTTPS before recording done. 165 1662.3 AMENDMENT TO PHASE 3: SLATE APPROVAL LIFECYCLE 167 1681. Slate member decision becomes a lifecycle with columns on the 169 existing slate member record: status in proposed, approved, 170 withdrawn, plus approved_by_user_id, approved_at, 171 withdrawn_by_user_id, withdrawn_at, and withdrawal_reason. 172 withdrawal_reason is required on every withdrawal and stored. 1732. Approve, one transaction taking FOR UPDATE on the member row: set 174 status and stamps, and where the slate is linked to a proposal, 175 increment proposal_staffing_links.approved_count. Audit through 176 OnTx. The approval appears in the proposal Staffing tab, readiness 177 inputs, and slate exports with who and when. 1783. Withdraw, same transaction discipline: requires the reason, sets 179 status and stamps, decrements approved_count, audits, and flags the 180 latest readiness snapshot stale. Withdrawal never deletes anything. 1814. Re approval after withdrawal is allowed. The audit trail carries the 182 full sequence. 1835. Both actions use the existing slate decision capability. Both notify 184 the capture owner and proposal owner through the alerts module. 1856. UI: approve and withdraw buttons on the slate member row, withdraw 186 opens a reason modal, the row shows current status with the latest 187 stamp. 188 189GATE 3 ADDITIONS: approve, withdraw, and re approve leave approved_count 190exactly correct under an eight way race, proven by racing it. A 191withdrawal without a reason is rejected by the API, not just the form. A 192withdrawal flips readiness staleness and the next snapshot reflects the 193reduced coverage. The full sequence is visible in the audit trail. 194 1952.4 AMENDMENT TO PHASE 5: DESK INTEGRATION 196 197A. Requisition to requirement bridge. Requisitions gain requirement_id. 198 Creating a job order offers two paths: link an existing requirement, 199 or create and link one using the same structured requirement fields 200 the platform already scores against. The frozen engine is reached 201 only through this bridge. Editing the linked requirement after 202 screenings exist marks those screening results stale, never 203 silently. 204B. Resume pipeline. Resume upload on the candidate record and through 205 the apply intake: sha256, versioned, stored through 206 internal/platform/storage, current flag, priors retained. Parsing 207 runs through docextract and extraction into draft profile 208 suggestions: skills, certifications, experience entries, and 209 clearance indicators always labeled clearance intelligence, self 210 reported. Suggestions are accepted or edited by the recruiter, 211 never silently applied. Duplicate detection on candidate create and 212 on apply matches email and phone and prompts to open or merge. 213C. Screen from the desk. On an application row, a Screen action runs 214 the screenMATCH evaluation against the requisition's linked 215 requirement. The result, score, band, caps applied, engine version, 216 timestamp, stores on the application and renders in the pipeline. 217 Re screening keeps history. A stale badge shows when the 218 requirement changed after the screening ran. screenMATCH's queue 219 lists desk originated screenings. 220 2212.5 AMENDMENT TO PHASE 5: PUBLISHING TO THE TENANT WEBSITE 222 2231. Requisition publish workflow. Visibility: internal_only or 224 published. Public label: open, on_hold, filled, closed. The publish 225 checklist requires title, public description, location or remote 226 with explicit applicant location requirements, employment type 227 (arrays supported, contract to hire is CONTRACTOR plus FULL_TIME), a 228 validThrough date, and apply enabled. Pay range and benefits 229 description are optional with the state warning from decision 13. 2302. mm_api public jobs handler renders three things per mapped tenant: 231 the careers index at public_base_url, one canonical detail page per 232 published open job at public_base_url plus a stable job slug, and 233 the apply endpoint. Canonical link tags point at the fg-talent.com 234 URLs. Cache headers allow nginx to cache briefly, purged on publish 235 and unpublish. Each detail page carries exactly one JobPosting 236 JSON-LD block mirroring the visible content: title, description, 237 datePosted, validThrough, hiringOrganization as the tenant, 238 jobLocation or remote with applicantLocationRequirements, 239 employmentType, optional baseSalary, and identifier as a 240 PropertyValue holding the internal requisition id. No JobPosting 241 markup on the list page. 2423. The nginx change on the fg-talent.com vhost is two location blocks 243 matched to that vhost's conventions: one proxying /careers/ to the 244 mm_api upstream with the tenant slug fixed server side, one for 245 /careers/apply with the rate limit zone. Claude Code drafts the 246 exact blocks, Joseph reviews before they touch the live vhost, and 247 the reload is verified with the zero 5xx sweep. The careers index 248 gets an internal link from the main navigation as part of the vhost 249 change. 2504. The brand template for FG Talent matches the existing site design 251 language, header, footer, typography, colors, so the careers 252 section reads as native. 2535. Embeddable feed. GET /jobs/{tenant_slug}/feed.json returns published 254 open jobs, and a small vanilla JS embed snippet renders them on any 255 other page, documented. For a mapped tenant the canonical 256 destination is always the proxied careers page. 2576. Apply intake, minimal: name, email, phone optional, resume upload, 258 and a consent checkbox rendering the tenant's configured notice 259 text from the Phase 4 notice system. Submission creates or dedupe 260 matches a candidate, creates an application in the applied stage, 261 records source career_site, stores the consent event with timestamp 262 and notice version. Honeypot plus rate limiting. Rollout beyond FG 263 Talent is one mapping row and one nginx block per client site. 264 2652.6 AMENDMENT TO PHASE 5: DESK WORKFLOW ADDITIONS 266 2671. Structured intake brief on every job order, three fixed blocks: role 268 context, candidate profile, and submission logistics, where 269 logistics means fee or rate terms, required submittal format, client 270 feedback SLA, interview process, and the approval contact. Sourcing 271 from an incomplete brief shows a warning, not a hard block. 2722. Pipelines per placement type. Job order type, permanent, contract, 273 contract to hire, temp, selects the stage template automatically. 2743. Client submittal records as explicit steps distinct from internal 275 submittal: packet reference, submitted_at, client feedback text, a 276 feedback reason code, and a feedback SLA timer that ages visibly. 277 This is the data model the future client portal renders. 2784. Reason taxonomy on every rejection and every backward stage move, 279 selected from a small configurable list plus free text. Reasons feed 280 the intake quality loop and the segregated adverse impact reporting 281 path, through the compliance role only, never the other direction. 2825. Days in stage aging on the pipeline board, thresholds configurable 283 per tenant, default flag when interview stage aging passes fifteen 284 days. 2856. Wire the existing activities and tasks tables into every record 286 surface: notes timeline and tasks with owners and due dates on 287 candidates, clients, requisitions, applications, and placements. 2887. Talent pools and saved searches: named candidate lists per recruiter 289 and team, add from any candidate list, saved search definitions, so 290 a repeat job order starts from the last search instead of zero. 2918. Status triggered alerts through the alerts module: stage change, 292 client feedback recorded, offer accepted or declined, assignment end 293 approaching. Drafted notifications, human send, per decision 14. 2949. Offers completed: status enum with extended, accepted, declined 295 stamps and a decline reason. Placement creation carries worksite, 296 pay rate, bill rate, start date, and approval contact forward from 297 the order and offer without retyping. 29810. Optional requisition approval chain per client: when a client is 299 flagged as requiring it, a manager approval step gates the order 300 going active. 30111. Client specific submittal requirements live on the client record, 302 format notes and process notes, surfaced automatically at submittal 303 time. 304 3052.7 FAST FOLLOW ADDITIONS 306 307Append to the directive's fast follow list: the client portal rendering 308the submittal and feedback model, read only, per client contact 309authentication; automated candidate engagement sequences on status 310triggers once a sending policy is decided; VEVRAA ESDS posting reusing 311the publish pipeline as its source of truth; knockout questions and 312reference check records on applications; a placement start onboarding 313checklist; and requisition and placement history import. 314 3152.8 GATE 5 ADDITIONS, PUBLISHING AND DESK 316 3171. Publish a job order in recruitMATCH and load it at 318 https://fg-talent.com/careers/ and its detail URL. curl shows the 319 full job content in the initial HTML response, no JS execution 320 required. 3212. The detail page carries exactly one JobPosting JSON-LD block that 322 mirrors the visible content and passes the Rich Results test. 3233. Submit the apply form from fg-talent.com: a candidate and an 324 application exist in the FG Talent tenant, stage applied, source 325 career_site, consent event stored with notice version, and the 326 duplicate check fires on a repeat email. 3274. Fill the order: the detail page is gone, the index no longer lists 328 it, the sitemap entry is removed, and the markup is nowhere. 3295. The missionMATCH domain path for the FG Talent slug issues a 301 to 330 fg-talent.com. 3316. Page and schema contain Patricia Cox and Brian Atwood only. A test 332 asserts the strings Tom and Glennette appear nowhere in rendered 333 output or JSON-LD. 3347. Unknown slug returns 404 with nothing leaked, and the apply rate 335 limit answers 429 under the race. 3368. The careers sitemap section regenerates on publish and on unpublish, 337 and GSC Request Indexing is exercised once manually and recorded. 3389. The feed renders on a test page. 33910. Screen from an application stores a banded result and goes stale 340 when the requirement changes. Resume parse produces suggestions and 341 never overwrites. Duplicate detection fires on a known email. 34211. An intake brief saves with all three blocks. A client submittal 343 records feedback with a reason code and its SLA timer ages. A 344 rejection carries a taxonomy reason. An accepted offer flows into a 345 placement carrying rates forward. 346 3472.9 ACCEPTANCE ADDITIONS 348 34925. Slate approval and withdrawal maintain correct counts under race, 350 and every withdrawal carries a stored reason. 35126. Public jobs surfaces expose only published data, resolve tenants by 352 slug only, and pass Rich Results validation on every live posting. 35327. Expired or filled postings drop their markup immediately, verified 354 by the sweep job's test. 35528. Apply intake stores a consent event with notice version for every 356 submission. 35729. Desk screenings reach the engine only through the requisition to 358 requirement bridge, and the engine diff remains empty. 359 360-------------------------------------------------------------------------------- 361AMENDMENT 4: UPLOADS AND THE IMPORT CENTER 362-------------------------------------------------------------------------------- 363 3644.1 DECISIONS RECORDED 365 3661. One upload subsystem, three entry points: the candidate record, the 367 recruitMATCH Import Center, and screenMATCH screen from resume. 368 Parsing, deduplication, storage, and versioning exist in exactly one 369 internal path that all three call. The apply intake uses the same 370 path. 3712. Every bulk import is staged, never direct. Files land in 372 import_batches and import_rows, then validate, then preview, then a 373 human commit writes live records. Extract, draft, review, approve, 374 promote. 3753. Import types shipping in Phase 5: single resume, resume bundle as 376 multiple files or one zip, candidate spreadsheet as CSV or XLSX, and 377 clients with contacts spreadsheet. 3784. Protected class columns are rejected at validation, by name pattern 379 and content sniffing: race, ethnicity, gender, sex, disability, 380 veteran status, and kin. EEO and self identification data never 381 enters through an import. The segregated compliance path is the only 382 door. 3835. Every imported candidate carries source import with a batch 384 reference, and committing a batch requires a first party attestation 385 checkbox, the tenant affirming the data was collected by their 386 organization from the candidates directly. The attestation, who, and 387 when are stored on the batch. 3886. File rules. Resumes: pdf, docx, txt, rtf, legacy doc rejected with a 389 clear resave message. Data: csv, xlsx. Bundles: zip only under the 390 archive safety rules. Size caps and per batch row caps are 391 configuration with sane defaults. 3927. Processing is asynchronous through a job binary. The UI shows live 393 progress and per row outcomes. Partial success is normal. Batches 394 are idempotent and resumable: every row records its action, reruns 395 skip completed rows. 396 3974.2 DATA MODEL 398 399All tables carry the standard invariants. 400 401import_batches: organization_id, id, kind, status, source_file_name, 402storage_key, sha256, size_bytes, row_count, created_count, merged_count, 403skipped_count, failed_count, dedupe_policy, mapping_id, 404attestation_checked, attestation_user_id, attestation_at, 405created_by_user_id, started_at, completed_at, created_at. kind enum: 406resume_single, resume_bundle, candidates_sheet, clients_sheet. status 407enum: uploaded, validating, ready_for_review, committing, completed, 408completed_with_errors, failed, cancelled. dedupe_policy enum: prompt, 409merge, skip, create. 410 411import_rows: organization_id, id, batch_id, row_number, 412source_file_name, raw_content_ref, parsed_payload, validation_errors, 413dedupe_match_candidate_id, action, created_candidate_id, 414created_client_id, created_contact_id, error_code, processed_at. action 415enum: pending, created, merged, skipped, failed. Nothing here is a live 416record until commit writes one and stores its id back on the row. 417 418import_mappings: organization_id, id, kind, name, column_map, 419created_by_user_id, created_at, updated_at. Saved column mappings so a 420recurring spreadsheet format maps once. 421 422Resume storage and versioning reuse the candidate record model: sha256, 423versioned, current flag, priors retained, bytes through 424internal/platform/storage. 425 4264.3 IMPORT CENTER, IN recruitMATCH 427 4281. Upload screen: import type picker, drag and drop with a file picker, 429 multiple files for bundles, single zip accepted, live progress, 430 allowlist and size enforcement with clear per file errors. 4312. Mapping screen for spreadsheets: source columns to candidate or 432 client fields, automatic suggestion by header name, saved templates 433 offered on header match, required field indicators, protected class 434 rejection surfaced here with the offending columns named. 4353. Review screen: counts by outcome, validation errors per row, dedupe 436 resolution with the batch policy as default and per row override, 437 matches shown side by side with the incoming row. 4384. Commit: attestation checkbox, then asynchronous commit with live 439 progress, final counts, and a per row error export through csvsafe. 4405. Batch history: every batch with status, counts, uploader, drill in 441 to rows. Cancellable before commit. Nothing about a committed batch 442 is ever deleted. 4436. Quick add stays: the single candidate form with inline resume 444 upload, wired to the same subsystem. 445 4464.4 screenMATCH ADDITIONS 447 4481. Screen from resume, single: upload one resume inside screenMATCH, 449 parse to draft profile, dedupe prompt on match, recruiter confirms 450 create or use existing, selects the requirement, evaluation runs. 451 Result stores with engine version and timestamp. Candidate carries 452 source resume_upload. 4532. Bulk screen against one requirement: upload a resume set or zip, a 454 resume_bundle batch is created with the requirement attached, and on 455 commit every created or matched candidate is evaluated against it. 456 The screening queue fills with banded results, failures listed per 457 file, nothing uncommitted is ever scored. 4583. Archive safety wherever zip is accepted: list entries first, enforce 459 per entry allowlist and size cap, cap entry count, reject nested 460 archives, reject path traversal. Extraction only after the listing 461 passes. 4624. The frozen engine is reached only through the existing evaluation 463 path. 464 4654.5 PROCESSING 466 4671. cmd/import-process: claims a batch, parses, validates, computes 468 dedupe candidates, and executes commit, each step bounded, 469 observable, audited, idempotent by row action, following the 470 sam-sync and queue conventions. 4712. Parsing through docextract and extraction. Spreadsheets parse in Go. 472 Per row failures never abort the batch. 4733. Large file behavior tested: a batch at the row cap completes with 474 memory bounded through streaming reads. 475 4764.6 GATE 5 ADDITIONS, IMPORTS 477 4781. Commit a three file resume bundle: three candidates exist with 479 parsed suggestions, sources read import, each traces to batch and 480 row. 4812. A planted duplicate triggers the dedupe prompt and a merge produces 482 one candidate, not a twin. 4833. A spreadsheet with a protected class column is rejected at 484 validation with the column named, and nothing reaches a live table. 4854. A five hundred row candidate spreadsheet commits with correct 486 counts, per row lineage, and a clean error export. 4875. Kill cmd/import-process mid commit and rerun: the batch completes 488 with no duplicates, proven by counts. 4896. Screen from resume produces a stored banded result and the dedupe 490 prompt fires on a known email. 4917. A bulk screen fills the screening queue and lists the one 492 deliberately corrupt file as failed. 4938. A zip with a path traversal entry and a zip with a nested archive 494 are both rejected at listing. 4959. Every commit stores the attestation with user and timestamp. 49610. An uncommitted batch is invisible to candidates, search, matching, 497 and slates, proven by query. 498 4994.7 ACCEPTANCE ADDITIONS 500 50130. No import writes a live record except through a committed batch, and 502 every imported record carries batch and row lineage. 50331. Protected class data cannot enter through any import path, proven by 504 the rejection tests. 50532. Import batches are idempotent under rerun and partial failure, with 506 counts that always reconcile to rows. 507 508-------------------------------------------------------------------------------- 509AMENDMENT 5: THE CANDIDATE SPINE AND THE DESK DATAFLOW 510-------------------------------------------------------------------------------- 511 5125.1 THE CANONICAL DATAFLOW, PERMANENT DIRECTIVE APPENDIX 513 514One candidate spine. One linking record. Everything hangs off it. 515 516 INTAKE CANDIDATE WORK 517 apply on fg-talent.com \ / desk pipeline 518 Import Center bulk \ / (applications) 519 screenMATCH resume > candidates table < proposal slates 520 quick add on the desk / one record per person \ screenings 521 (all paths dedupe) / all tools, same spine \ pools, searches 522 523 THE LINKING RECORD: application (candidate x requisition) 524 exactly one active application per candidate per requisition 525 526 requisition (job order, openings count, linked requirement) 527 | 528 | add to job order (from match, search, pool, or manual) 529 v 530 application: prescreen -> internal submittal -> client submittal 531 -> interview -> offer -> placed 532 or out at any stage, always with a reason code 533 | 534 | offer accepted 535 v 536 placement takes a seat under the existing FOR UPDATE seat lock 537 | 538 v 539 JOB ORDER UPDATES ITSELF 540 stage counts derive live on the order 541 last seat placed flips status to filled in the same transaction 542 remaining active applications become filled_by_another, notified 543 filled unpublishes the fg-talent.com page via the expiry sweep 544 a fall off frees the seat, reopens the order, alerts the owner, 545 and never republishes without a human confirming 546 | 547 v 548 placement end approaching -> redeployment alert -> candidate returns 549 to the available pool -> the spine loops 550 551Both match directions use the same frozen engine: a job order ranks 552candidates, and a candidate ranks open job orders, both reading through 553the requisition to requirement bridge. screenMATCH is the deep evaluation 554of one pairing, stored on the application. slateMATCH is the proposal 555branch off the same spine, and a person may sit on a slate and in a desk 556pipeline at once because both point at one candidate record. 557 5585.2 DECISIONS RECORDED 559 5601. One candidate spine. The missionMATCH command center Candidates 561 screen and the new desk page read the same records. Shared candidate 562 profile components are extracted into a shared frontend directory 563 and composed by both surfaces. Nothing candidate shaped is 564 duplicated per tool. 5652. recruitMATCH gains a Candidates page in its navigation, gated by the 566 recruitmatch entitlement. 5673. Candidate search on the page is deterministic SQL: the existing 568 hybrid fusion, tsvector rank with pgvector cosine joined by 569 reciprocal rank fusion, exposed as a repository query with 570 structured filters. The AI Ask path is untouched and separate. 5714. Reverse matching runs the frozen engine, one candidate against the 572 linked requirement of every open requisition. Orders without a 573 linked requirement appear as unmatchable with a fix it link to the 574 bridge. Every computed pairing persists with score, band, engine 575 version, and computed_at, and goes stale when the requirement or the 576 candidate profile changes after computation. 5775. Add to job order creates the application. Exactly one active 578 application per candidate per requisition, enforced by a partial 579 unique index over non terminal statuses. Adding a candidate whose 580 prior application on that order ended requires an explicit reopen 581 with a taxonomy reason. 5826. Applications record how they began: added_from in apply, import, 583 match, search, pool, manual, screen. When added from match, the 584 score snapshot, band, and engine version at add time are stored on 585 the application. 5867. The default stage template gains internal_submittal and 587 client_submittal as explicit stages. Existing stage values are never 588 renamed and never destroyed; the template extends, historical data 589 stands, derive.go and analytics read the extended set. Placement 590 type templates build on this default. 5918. Job order status is a state machine: draft, open, on_hold, filled, 592 closed. Filling the last seat flips open to filled automatically 593 inside the placement transaction the seat lock governs. A fall off 594 frees the seat and flips filled back to open automatically, with an 595 alert. Manual transitions remain, and every transition, automatic or 596 manual, is audited with its cause. 5979. filled_by_another is a distinct application outcome, not a 598 rejection. When an order fills, remaining active applications move 599 there in the same transaction, their candidates flagged available, 600 owners notified through alerts. 60110. Republishing after a fall off requires a human confirm on the 602 requisition. The page never reappears on fg-talent.com silently. 603 6045.3 THE CANDIDATES PAGE, IN recruitMATCH 605 6061. Roster list: name, headline or current title, clearance intelligence 607 level, top skills, location, availability, source, last activity, 608 active pipelines count, pools. Sortable, virtualized. 6092. Filters: clearance intelligence level, skills, certifications, 610 location and radius or remote, availability window, source, pool, 611 has resume, last activity age. Free text runs the fusion query. 612 Saved searches apply here, save and rerun. 6133. Bulk actions on selected rows: add to pool, add to job order, export 614 through csvsafe. 6154. Candidate detail, composed from shared components, tabs: Profile 616 (clearance intelligence always labeled self reported), Resumes 617 (version list, inline viewer, download, upload new version), 618 Screenings (every screenMATCH result with engine version, band, and 619 stale badges), Pipelines (every application across orders with 620 client, order, stage, status, aging), Activity and Tasks, Pools. 6215. Detail actions: Match to open orders, Add to job order, Screen 622 against an order, Add to pool, Edit profile, Upload resume. 623 6245.4 REVERSE MATCH, CANDIDATE TO OPEN ORDERS 625 6261. Match to open orders opens a ranked list: every open requisition 627 with a linked requirement, scored by the frozen engine, showing band 628 chip, score, client, order title, openings remaining, deadline or 629 aging, and whether this candidate already has an application there. 6302. Row actions: Add to pipeline, creating the application with the 631 match snapshot, and Screen now, running the full screenMATCH 632 evaluation on the pairing. Multi select add supported. 6333. Unmatchable orders list at the bottom with a link opening the bridge 634 flow. 6354. Determinism: same candidate and same open orders produce the same 636 ranking every run, decimal arithmetic, no model in the loop. Stale 637 pairings recompute on open; persisted history is never overwritten. 638 6395.5 ADD TO JOB ORDER, MECHANICS 640 6411. One transaction: FOR UPDATE on any existing application row for the 642 pair, insert or reopen, write added_from and the snapshot when 643 present, write the activity, audit through OnTx. Eight racing adds 644 produce one application. 6452. Requisition list and detail show live stage counts, in pipeline, 646 internal submittal, client submittal, interview, offer, placed, and 647 out, derived by indexed query, plus openings remaining from 648 placements. Stat tiles click through to the filtered pipeline. 6493. Client detail shows its orders with the same counts, so find a 650 candidate, match them, add them to the client's open order is two 651 clicks from either end and the order reflects it immediately. 652 6535.6 JOB ORDER SELF UPDATES 654 6551. Filling the last seat, inside the placement transaction: requisition 656 status to filled, remaining active applications to filled_by_another 657 with notifications, publish state to unpublished with the sitemap 658 entry dropped by the sweep, audited with cause placement_final. 6592. Fall off: a placement ending before its scheduled end frees the 660 seat, flips filled to open with cause fall_off, alerts the order 661 owner and the capture owner where linked, leaves the page 662 unpublished pending human republish. filled_by_another candidates on 663 that order can be reactivated to their prior stage manually, one 664 click, audited. 6653. on_hold pauses publishing and SLA timers without disturbing the 666 pipeline. closed is terminal, requires a reason, moves active 667 applications to out with reason order_closed. 668 6695.7 GATE 5 ADDITIONS, CANDIDATES AND DATAFLOW 670 6711. The Candidates page finds a planted candidate by skills filter and 672 by free text through the fusion query, and the missionMATCH command 673 center Candidates screen still renders from shared components with 674 zero regression. 6752. Reverse match on a fixture candidate returns an identical ranking 676 across repeated runs, and the engine diff against the starting 677 commit remains empty. 6783. Add to job order from the match list creates the application with 679 the score snapshot and added_from match. Eight racing adds of the 680 same pair produce exactly one application. A duplicate add through 681 the API is rejected. 6824. Stage counts on the requisition update as the application moves 683 through prescreen, internal submittal, client submittal, interview, 684 and offer, and each tile clicks through correctly. 6855. Placing the final seat flips the order to filled, moves remaining 686 fixture applications to filled_by_another with alerts recorded, and 687 the fg-talent.com detail page and sitemap entry are gone. 6886. A simulated fall off frees the seat, reopens the order with an 689 alert, does not republish, and a one click reactivation restores a 690 filled_by_another candidate to their prior stage, audited. 6917. Re adding a previously rejected candidate demands a reopen reason 692 and records it. 6938. A candidate on a proposal slate and in a desk pipeline resolves to 694 one candidate id everywhere. 695 6965.8 ACCEPTANCE ADDITIONS 697 69833. Exactly one active application exists per candidate per requisition, 699 enforced by the database, proven by the race. 70034. Every job order status transition, automatic or manual, carries an 701 audited cause, and filled_by_another is distinguishable from 702 rejection in every report. 70335. Reverse match rankings are bit reproducible, persisted with engine 704 version, and the frozen engine remains untouched. 705 706-------------------------------------------------------------------------------- 707FINAL MERGE INDEX, VERIFY AFTER APPLYING 708-------------------------------------------------------------------------------- 709 7101. Directive Section 0 gained the Amendment 1 environment rule. 7112. Phase 3 gained the slate approval lifecycle. Gate 3 gained its 712 additions. 7133. Phase 5 gained: desk integration A through C, publishing to the 714 tenant website, desk workflow additions 1 through 11, the Import 715 Center and screenMATCH uploads, the Candidates page, reverse match, 716 add to job order, and job order self updates. Gate 5 gained sections 717 2.8, 4.6, and 5.7. 7184. The directive gained the canonical dataflow as a permanent appendix. 7195. Section 11 gained acceptance items 25 through 35. 7206. Task T1 is registered as standalone work. 7217. The fast follow list gained the 2.7 items. 722Record "consolidation merged and verified" in BUILD_STATE when all seven 723lines above are true in the working plan. 724