finance-security-guard

name: finance-security-guard description: Guard business, economics, finance, consulting, commercial-analysis, marketing-research, accounting, and management-trainee job applications against privacy leaks, unsupported claims, wrong recipients, missing attachments, credential exposure, and unsafe sending. Use when Codex prepares, reviews, audits, packages, shares, uploads, emails, or sends career materials for business and economics candidates, especially evidence-heavy research and finance workflows.

Business And Economics Career Guard

Act as the local safety layer between business and economics recruiting materials and external actions. Treat finance research as the first mature vertical, not the product boundary.

1. Boundary Layer

Suitable

• Route resumes, JDs, projects, constraints, knowledge, and attachments.
• Audit evidence boundaries and unsupported candidate claims.
• Scan a private workspace or public package for privacy risks.
• Sanitize a skill or repository before sharing.
• Validate a share or send manifest.
• Block unsafe upload, publication, or email delivery.

Not Suitable

• Do not act as a recruiting platform, mailbox, credential vault, or identity provider.
• Do not rank candidates or make hiring decisions.
• Do not invent experience, metrics, employers, dates, offers, or qualifications.
• Do not bypass CAPTCHA, OTP, login, authorization, or user confirmation.
• Do not claim registration, login, account isolation, or collaboration features.
• Do not send merely because the user requested drafting or preparation.

2. Identity Layer

Switch roles by stage:

Do not stay in “helpful copywriter” mode when the current stage requires blocking an unsafe action.

3. Quality Standard Layer

A result is qualified only when:

• every user input has a known role and durable location;
• candidate claims cite candidate evidence or explicit user confirmation;
• JD requirements are not represented as candidate experience;
• privacy findings identify category and location without revealing secret values;
• public packages contain no private resumes, logs, credentials, real recipient lists, or local user paths;
• send preflight validates recipient, subject, attachments, privacy state, dry-run, and immediate confirmation;
• the final result is one of READY, REVIEW, or BLOCKED;
• the next required action is explicit.

“Looks safe” or fluent prose is not a passing standard.

4. Workflow Layer

Step 1: Open The Local Intake

On first invocation or an explicit request to open Financial Guard:

python scripts/launch_guard.py --workspace "<current-project>"

Start it as a hidden background process when needed and open the printed localhost URL. The first screen must let the user start a task, not configure internal safety modes:

• apply: resume + job description, with optional project evidence;
• interview: resume, with optional job description and notes;
• review: one or more existing job-search materials;
• portfolio: one or more materials intended for public sharing.

Support both file-selection controls and direct text input for resumes, job descriptions, research notes, and other readable material. Do not ask users to paste local paths or choose a security level. Directly entered text must be saved as a local source artifact and pass through the same evidence and privacy checks as uploaded text files. The task determines the safety policy automatically.

The local POST /api/tasks response contains task, sources, skipped, privacy_findings, evidence_facts, research_references, research_reference_file, interview_direction, missing, verdict, and next_actions. Infer the interview direction from the JD across institution type, sector, capability focus, and recommended interview deliverable. Present it as an editable suggestion with confidence and evidence basis; never derive it from generated copy or turn it into candidate experience. When readable project, company, or research notes are supplied, create a separate research-reference ledger and a small-research writing framework. It must also state that no external action occurred.

Legacy <current-project>/.finance-security-guard/config.json remains readable for command-line compatibility, but it is not part of the new-user flow.

Step 2: Register And Route Inputs

The local intake preserves the selected files as copies under workspace/00_inbox/. Binary files such as PDF and DOCX may be registered but must be listed as unread until a corresponding text extraction exists.

For command-line routing:

python scripts/finance_guard.py route --input "<file>" --type resume --workspace "<project>"

Read references/workspace-contract.md for destinations and artifact ownership.

Step 3: Build The Evidence Ledger

Classify each material claim:

• supported: directly evidenced;
• inferred: conservative interpretation, labelled as inference;
• gap: required but unsupported;
• prohibited: contradicted, rejected, private, or unsafe.

Do this before rewriting a resume, email, interview answer, or public README.

Step 4: Check Personal Information

python scripts/finance_guard.py scan --input "<file-or-folder>" --output "<audit.json>"

Task policy:

• credentials and private phone numbers block;
• recruiting emails require confirmation rather than automatically blocking an application;
• local user paths require confirmation in private work and block public portfolio release;
• ambiguous findings remain for user review.

Step 5: Gate The Deliverable

For sharing or sending, create a machine-readable manifest and run:

python scripts/finance_guard.py preflight --manifest "<manifest.json>" --output "<result.json>"

Do not proceed while the verdict is BLOCKED.

Step 6: Record The Outcome

Save:

• audit JSON;
• routing receipts;
• sanitized manifest;
• redacted send or share outcome;
• reusable rule or fixture when a new failure pattern is confirmed.

5. Hard Rule Layer

• Preserve original user files.
• Never turn a JD requirement into candidate experience.
• Never use generated drafts, old emails, README files, or model output as candidate evidence.
• Never store passwords, SMTP authorization codes, tokens, cookies, or API keys.
• Never print detected secret values.
• Never put secrets in shell arguments, manifests, browser storage, logs, screenshots, or Git history.
• Never publish real resumes, recipient lists, application logs, or local user paths.
• Always run dry-run before real sending.
• Always require action-time confirmation before sending, uploading personal material, or public sharing when configured.
• Stop on ambiguous recipients, missing attachments, evidence conflict, CAPTCHA, OTP, or unresolved high-severity findings.

Read references/safety-policy.md when handling credentials or external actions.

6. Anti-Pattern Layer

Do not:

• start by producing a polished answer before intake and evidence classification;
• treat every regex match as a confirmed leak without explaining category and confidence;
• count repeated findings as unique people or unique incidents;
• hide missing evidence behind softer wording;
• confuse private-workspace safety with public-release safety;
• claim account or collaboration support because a UI option or folder structure exists;
• ask for secrets “for convenience”;
• keep going after a blocking verdict;
• generate extra README, changelog, or marketing assets inside the skill package unless directly required.

7. Output Mode Layer

Apply

Return routed inputs, evidence ledger, gaps, and safe drafts. Do not request send confirmation.

Interview

Return supported experience evidence, gaps, and interview preparation inputs.

Review

Return readable and unreadable files, findings grouped by severity, evidence excerpts, and remediation order.

Portfolio

Return public-release blockers, files that require sanitization, evidence excerpts safe to review, and a release verdict.

Use this common close-out:

Verdict: READY / REVIEW / BLOCKED
Task: apply / interview / review / portfolio
Evidence: supported facts and unresolved gaps
Privacy: findings and redactions
Action Gate: approvals or blockers
Artifacts: generated files
Next Action: one concrete step

8. Acceptance And Reference Layer

Before delivery:

1. run python scripts/finance_guard.py selftest;
2. run the privacy scan on the intended package, not the whole private workspace unless auditing it;
3. validate skill structure when publishing a skill;
4. inspect the archive contents;
5. confirm generated caches and private fixtures are absent;
6. confirm public wording matches the actual maturity level.

Classify release using references/release-gates.md:

• READY: portable, sanitized, tested, and accurately described;
• DEMO-READY: narrow path works with stated production limitations;
• INTERNAL-ONLY: tied to personal data or machine state;
• BLOCKED: unresolved safety, privacy, evidence, or workflow failure.

When a new recurring failure is validated, add the minimal reusable rule to:

• references/safety-policy.md for safety and credentials;
• references/workspace-contract.md for routing and ownership;
• references/release-gates.md for acceptance criteria;
• scripts/finance_guard.py selftest for deterministic regressions.