OCF → career-ops: seeding a workspace from a candidate-owned career file

[dmadeo]

Hi Santiago,

I maintain Open Career Format (OCF), an open, candidate-owned schema for durable career memory. OCF and career-ops look complementary: career-ops runs the job-search workflow, OCF holds the durable career context (facts, evidence, variants, cautions, stories, provenance) a candidate carries across tools.

I've already built the OCF side of this. There's a skill that exports a candidate's existing OCF file into career-ops' user-layer files (cv.md, profile, story-bank, jds) as it would expect. Career-ops runs exactly as it does today, without knowing OCF exists.

Two choices you might care about: it inspects your workspace's own templates before writing and adapts if your file shapes differ, so it won't freeze or hardcode your formats; and it holds a hard boundary, no pipeline/scoring/scan state ever flows back into OCF, and transient overlay like comp or location isn't written to the master without explicit consent.

Full write-up, the skill, the mapping notes, and the OCF repo:

• OCF - Career-Ops integration page
• export skill
• mapping notes
• OCF on GitHub

We seem aligned on what you laid out in the Vision thread: free, local-first, the candidate owning their own words. One thread here already has an OCF answer: multiple CV versions (#386) is what OCF's positioning and narrative variants are for.

A deeper tie could be interesting later as an integration: career-ops reading OCF directly as the substrate, curating per search track, and feeding user-approved career-memory improvements back. If that's worth exploring, I'm glad to write it up as an RFC following your process.

Nothing needed on your end for the skill/export to be useful today. Happy to compare notes, and thanks for building this.

— David

[santifer]

Answered your hook-contract question over in #1335, @dmadeo — short version: the plugin skill layer is your path today (local, zero-key, same session), no engine change needed, and career-ops-plugin-ocf would be a welcome registration. The template-inspection-before-writing and hard-boundary choices you made here are exactly the right instincts. Nice work.

[dmadeo]

@santifer - One small, non-OCF-specific question surfaced while implementing the connector.

Career-Ops classifies article-digest.md as user-layer proof-point data in DATA_CONTRACT.md, and update-system.mjs includes it in USER_PATHS, so updates will not overwrite it. Unlike cv.md, config/profile.yml, modes/_profile.md, and interview-prep/*, however, article-digest.md is not ignored by the default .gitignore.

Is that intentional? If not, would you consider adding article-digest.md to .gitignore and covering the relationship with a small test?

Existing tracked files would remain tracked, so this would only make the safer behavior the default for new files.

[dmadeo]

@santifer One related upgrade case surfaced while testing this. Current Career-Ops source already ignores interview-prep/* and local/, but an installation upgraded from 1.10 to 1.24 retains its older .gitignore, so those newer protections are absent. article-digest.md remains unignored in both cases.

Would it make sense for the updater to apply narrowly scoped, idempotent .gitignore migrations for newly classified user-layer paths, while preserving user-added rules? That would address article-digest.md for new and upgraded installs and carry existing protections such as interview-prep/* and local/ into older workspaces.

Or at least a warning message since they may contain personal data?

[dmadeo]

It looks like #2365 already fixed the article-digest.md issue. Sorry, I found this independently and missed the existing PR.
My follow-up point about older installations retaining stale .gitignore rules may still apply: either an idempotent migration that preserves local rules, or at least a warning when expected user-layer protections are missing.

[dmadeo]

As I read #2857 , I realized it addressed the reconciliation for existing installs. I think my comments are closed out. The ocf-careerops plugin work continues...