[codex] Add projectgraph skill

[SongkunChen]

Summary

Adds a projectgraph skill for initializing and maintaining a trace-backed, human-readable ProjectGraph inside Codex projects.

ProjectGraph is intentionally a record/display layer, not a task manager, governance system, automatic memory authority, or decision engine. It stores one canonical graph plus hidden provenance, then renders selected views as a local mind map.

What This Skill Adds

• Bootstrap for .projectgraph/ in a target project.
• PROJECT_GRAPH.json as the canonical graph.
• PROJECT_GRAPH.md as a readable Markdown outline.
• TRACE_INDEX.json for node-to-source mapping.
• Trace templates and Codex JSONL locator capture.
• Local Markmap viewer assets.
• Validators for graph/source drift, forbidden fields, missing trace files, Codex JSONL locators, vendor checksums, and view references.

Important Boundaries

• Visible graph nodes only contain conclusions, facts, problem structure, route tradeoffs, and logic chains.
• Provenance is hidden in traces and TRACE_INDEX.json.
• capture_codex_trace.py writes locator keyframes only; it does not rewrite the visible graph.
• The skill does not introduce confidence, status, RawTrace, LiveMindMap, or StableMap.
• Hooks are optional; the first-class workflow remains agent-mediated trace -> graph/index update -> validation.

Markmap Vendor Rationale

The viewer runtime is vendored so a generated ProjectGraph can be viewed locally without CDN access and without sending project structure to third-party asset hosts. The vendor bundle is version-pinned and covered by checksums.

Third-party runtime components:

• Markmap packages 0.18.12: MIT license.
• D3 7.9.0: ISC license.

This PR now includes:

• VENDOR_MANIFEST.json with package, version, license, source URL, and sha256 fields.
• THIRD_PARTY_NOTICES.md for the vendored runtime.
• release checks that verify vendor files, checksums, notices, and absence of CDN fallback in the viewer HTML.

If maintainers prefer a smaller first release, I am happy to make the viewer optional or move the skill to an experimental path first.

How To Review Locally

python3 skills/.curated/projectgraph/scripts/check_release.py \
  --skill-root skills/.curated/projectgraph

python3 skills/.curated/projectgraph/scripts/bootstrap_projectgraph.py \
  --target /private/tmp/projectgraph-official-smoke \
  --project-name OfficialSmoke

python3 /private/tmp/projectgraph-official-smoke/tools/projectgraph/validate_projectgraph.py \
  --root /private/tmp/projectgraph-official-smoke

Then open:

/private/tmp/projectgraph-official-smoke/.projectgraph/PROJECT_GRAPH.html

The viewer supports the default graph view plus perspective projections through display.views.

Reviewer Notes

The main review questions are:

• Should this land in .curated now, or start in .experimental?
• Is vendored Markmap acceptable with manifest, checksums, and third-party notices?
• Are the privacy boundaries around Codex transcript locators clear enough?
• Is the scope appropriately limited to project record keeping?

[SongkunChen]

Hi @xl-openai, would you be willing to review this ProjectGraph skill when you have a chance?

I am requesting you because this PR touches Codex skill authoring/workflow patterns and includes bundled scripts plus a vendored local viewer runtime. If another maintainer owns this area more directly, I am happy to redirect.

The PR body now calls out the main review questions explicitly:

• whether this belongs in .curated now or should start in an experimental path
• whether the vendored Markmap runtime is acceptable with checksums and third-party notices
• whether the Codex transcript locator privacy boundary is clear enough
• whether the skill is scoped narrowly enough as a project record/display layer rather than a task or governance system