Add Codex Radar publisher workflow

.gitignore

@@ -1,5 +1,6 @@
 # AI
 .codex
+.decodex
 
 # Editor
 .vscode

README.md

@@ -22,6 +22,10 @@ Repo-native agent orchestration and public Codex signal publishing.
 - Static Astro site that publishes GitHub-backed Codex change signals.
 - Deterministic GitHub signal pipeline for change bundles, release deltas, rendered
   signal entries, and content validation.
+- Repo-local Radar skills for upstream Codex triage, code analysis, release analysis,
+  signal drafting, and X post drafting.
+- Publisher workflow for checked-in upstream impact classification and reviewable X
+  drafts for `@decodexspace`.
 - Installable Decodex plugin with reusable agent-facing skills for manual CLI,
   automation, commit, land, and labels.
 - Repository documentation split by question type into spec, runbook, reference, and
@@ -55,17 +59,24 @@ runtime.
 - `scripts/github/` owns deterministic GitHub bundle, release-delta, render, and
   validation scripts.
 - `artifacts/github/` owns checked-in GitHub bundles and editorial analysis drafts.
+- `artifacts/archive/` owns checked-in recovery manifests for cold Radar batches stored
+  as GitHub Release assets.
+- `artifacts/social/` owns checked-in Publisher social draft artifacts.
 - `plugins/decodex/` owns the installable Decodex plugin and reusable agent-facing
   skills.
-- `dev/skills/` owns repository-development skill-like instructions that are not
-  packaged with the installable Decodex plugin.
+- `dev/skills/` owns repository-development skills for Radar analysis and Publisher
+  drafting. They are not packaged with the installable Decodex plugin.
 - `docs/` remains the authoritative documentation surface.
 
 Runtime authority stays in `apps/decodex/src/`, the registered project contracts under
 `~/.codex/decodex/projects/<service-id>/`, and the governing specs under `docs/spec/`.
 Public site authority stays in `site/`, `scripts/github/`, `artifacts/github/`, and
 the site/content specs.
 
+Historical Radar trace is local by default. `scripts/github/sync_latest_signals.py`
+writes `.decodex/radar.sqlite3` so every inspected upstream commit can be tracked
+without publishing every low-level or skipped item to the static site or Git history.
+
 ## Runtime platform support
 
 - The Decodex runtime contract is Unix-only: macOS and Linux.
@@ -151,13 +162,20 @@ The GitHub-first public signal path stays deterministic and reviewable:
 
 - `scripts/github/build_change_bundle.py` builds normalized GitHub bundles under
   `artifacts/github/bundles/`.
-- `dev/skills/github-signal/SKILL.md` records the repo-local Codex editorial
-  instructions. It is not part of the installable Decodex plugin distribution.
-- `scripts/github/sync_latest_signals.py` discovers recent merged PRs and refreshes
-  content artifacts.
+- `dev/skills/README.md` routes the repo-local Radar and editorial instructions. They
+  are not part of the installable Decodex plugin distribution.
+- `scripts/github/sync_latest_signals.py` discovers recent upstream commits, resolves
+  them back to PRs when possible, and refreshes content artifacts.
+- `scripts/github/backfill_release_range.py` fills release-window gaps before a
+  release or prerelease summary, but daily Radar still starts from the commit stream.
+- `docs/spec/upstream-impact.md` records how upstream Codex changes are classified for
+  public signals and Control Plane follow-up work.
 - `scripts/github/render_signal_entry.py` renders reviewed analysis drafts into site
   content.
 - `scripts/github/validate_signal_entry.py` validates the published signal collection.
+- `docs/spec/social-post-draft.md` and
+  `docs/runbook/social-publishing-workflow.md` govern optional checked-in X drafts
+  before external publication.
 - `.github/workflows/refresh-github-signals.yml` refreshes GitHub-backed signals every
   hour from a trusted runner.
 - `.github/workflows/deploy-pages.yml` publishes the Astro site to GitHub Pages on
@@ -216,8 +234,8 @@ The tracked workspace currently keeps:
   validation script surface
 - `artifacts/github/` as checked-in GitHub bundle and analysis artifacts
 - `plugins/decodex/` as the canonical installable Decodex plugin source
-- `dev/skills/` as repo-development skill-like instructions that are not packaged with
-  the installable Decodex plugin
+- `dev/skills/` as repo-development Radar analysis and Publisher drafting skills that
+  are not packaged with the installable Decodex plugin
 - `docs/spec/` as the normative runtime, workflow, site, and content contract lane
 - `docs/runbook/` as the operator procedures, validation sequences, deployment steps,
   and content workflow lane

artifacts/archive/README.md

@@ -0,0 +1,8 @@
+# Archive Manifests
+
+This directory stores Git-tracked manifests for cold Radar archive batches.
+
+Compressed archive payloads do not live in Git. Store them as GitHub Release assets under
+dedicated `radar-archive-*` tags, then keep the recovery manifest in `index/`.
+
+The governing contract is `docs/spec/radar-artifact-retention.md`.

artifacts/archive/index/.gitkeep

@@ -0,0 +1 @@
+

artifacts/github/README.md

@@ -4,6 +4,11 @@ This directory stores checked-in GitHub signal pipeline artifacts.
 
 - `bundles/` holds normalized `github_change_bundle/v1` inputs.
 - `analysis/` holds reviewed Codex editorial analysis drafts.
+- `impact/` holds optional `upstream_impact/v1` classifications.
+
+`bundles/` and `analysis/` are hot raw artifact directories. Keep raw entries in Git for
+at most 28 days, then move cold batches to dedicated `radar-archive-*` GitHub Release
+assets and keep the recovery manifest under `artifacts/archive/index/`.
 
 Executable automation for these artifacts lives under `scripts/github/`. Repo-local
 editorial instructions live under `dev/skills/github-signal/`.

artifacts/github/impact/.gitkeep

@@ -0,0 +1 @@
+

artifacts/social/README.md

@@ -0,0 +1,9 @@
+# Social Artifacts
+
+This directory stores checked-in Publisher artifacts for external social channels.
+
+- `x/` holds `social_post_draft/v1` drafts for X/Twitter publication.
+
+Drafts are review artifacts. A draft is not approved for external publication until its
+`status` is `approved` under the rules in `docs/spec/social-post-draft.md` and
+`docs/runbook/social-publishing-workflow.md`.

artifacts/social/x/.gitkeep

@@ -0,0 +1 @@
+

dev/skills/README.md

@@ -0,0 +1,42 @@
+# Decodex Dev Skills
+
+Purpose: Route repo-local development skills for the Decodex Radar and Publisher
+pipeline.
+
+These skills are checked-in repository-development instructions. They are not packaged
+with the installable Decodex plugin under `plugins/decodex/`.
+
+## Skill Map
+
+Use these skills in order when turning upstream Codex activity into Decodex content or
+follow-up work:
+
+1. `codex-upstream-triage`: choose which upstream commits, PRs, releases, or changelog
+   entries deserve deeper analysis.
+2. `codex-code-analysis`: read the selected upstream code or patch evidence and map it
+   to user-visible, Control Plane, and Publisher implications.
+3. `codex-release-analysis`: evaluate release or changelog material against commits,
+   PRs, release-delta artifacts, and already-published Decodex signals.
+4. `github-signal`: turn the reviewed GitHub bundle and analysis result into the
+   `analysis_draft` JSON consumed by `scripts/github/render_signal_entry.py`.
+5. `x-post-draft`: turn evidence-backed Radar output into a reviewable
+   `social_post_draft/v1` artifact for `@decodexspace`.
+
+Use only the skills needed for the current artifact. Do not create a social draft just
+because a signal exists.
+
+Default posture: track every upstream Codex commit as a possible evidence unit. Resolve
+commits back to PRs when possible, decide whether the change matters to Decodex Control
+Plane or the wider Codex community, and only then promote important, useful, or
+deprecated behavior into a signal, upstream-impact artifact, follow-up issue, or X
+draft.
+
+For upstream releases and prereleases, use `codex-release-analysis` as a rollup over
+the accumulated commit/PR analysis. Codex prerelease notes are often too sparse to
+explain what changed by themselves.
+
+Only the existing checked-in contracts are durable artifacts today:
+`github_change_bundle/v1`, `analysis_draft`, `signal_entry/v1`, `upstream_impact/v1`,
+`release_delta/v1`, and `social_post_draft/v1`. The triage, code-analysis, and
+release-analysis skills are reasoning passes unless their conclusions are promoted
+into one of those contracts.

dev/skills/codex-code-analysis/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: codex-code-analysis
+description: Use when reading upstream OpenAI Codex PR, commit, file, or patch evidence to understand what changed, whether it is user-visible, and how it affects Decodex Radar, Control Plane, Publisher, or follow-up engineering.
+---
+
+# Decodex Codex Code Analysis
+
+Use this skill after upstream triage chooses a candidate. Its job is to turn source
+evidence into a defensible interpretation, not to rewrite release notes.
+
+This is a Decodex repository-development instruction surface, not an installable
+Decodex plugin skill.
+
+## Read Before Analysis
+
+- `docs/spec/github-change-bundle.md`
+- `docs/spec/upstream-impact.md`
+- `docs/spec/signal-entry.md`
+- `dev/skills/README.md`
+
+## Inputs
+
+- A `github_change_bundle/v1` under `artifacts/github/bundles/`, or enough GitHub PR or
+  commit evidence to request or create one
+- Optional release or changelog context
+- Optional existing Decodex signal, upstream-impact, or release-delta artifacts
+
+This skill does not define a new checked-in artifact. Keep the result in-session
+unless it is promoted into an existing `analysis_draft`, `upstream_impact/v1`, or
+`social_post_draft/v1` contract.
+
+## Analysis Loop
+
+1. Identify the changed surface.
+   - Public API/protocol/schema
+   - CLI/TUI/app-server behavior
+   - Config, permission, sandbox, auth, provider, hook, or plugin behavior
+   - Docs, examples, tests, or internal-only refactor
+
+2. Follow the runtime path.
+   - Start from the PR title/body when `analysis_mode = "pr_first"`.
+   - Use changed files and patch excerpts to locate the actual behavior boundary.
+   - Use tests and docs as confirmation, not as the only proof.
+   - Read enough surrounding code to know whether the change is shipped behavior,
+     plumbing, guardrail, or cleanup.
+
+3. Map implications.
+   - User path: what a normal Codex user can observe or try.
+   - Control Plane path: what Decodex runtime, app-server integration, plugin routing,
+     tracker tooling, or automation policy may need to adopt or guard.
+   - Publisher path: what can be explained publicly without overclaiming.
+
+4. Assign confidence.
+   - `confirmed`: source patch plus tests, docs, schema, CLI help, or public release
+     evidence point to the same behavior.
+   - `likely`: code strongly implies behavior, but no public docs or direct test covers
+     the exact user path.
+   - `weak`: evidence is names, commit titles, sparse release notes, or incomplete patch
+     excerpts.
+
+## Evidence Standards
+
+Prefer concrete anchors:
+
+- changed protocol/schema files
+- config-schema or CLI flag changes
+- tests that exercise visible behavior
+- docs or examples that describe the behavior
+- app-server, plugin, MCP, browser, sandbox, hook, auth, provider, or tool-handler code
+
+Do not treat these as enough by themselves:
+
+- internal file names
+- generic commit titles
+- social engagement
+- release bodies that only repeat the version number
+- TODOs or comments without behavior
+
+## Output
+
+Return an analysis note that can feed `github-signal`, `codex-release-analysis`, or
+`upstream_impact/v1`:
+
+- one-sentence observed change
+- changed surface classification
+- evidence anchors
+- user-visible path, if any
+- Control Plane impact, if any
+- Publisher angle, if any
+- confidence and caveats
+- recommended next artifact: `none`, `analysis_draft` through `github-signal`,
+  `upstream_impact/v1`, or `social_post_draft/v1`
+
+Keep the note shorter than the source patch. Explain the behavior path, not every
+changed file.

dev/skills/codex-release-analysis/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: codex-release-analysis
+description: Use when evaluating upstream Codex releases, prereleases, app updates, or changelog entries and deciding what Decodex should publish, watch, or absorb from the release.
+---
+
+# Decodex Codex Release Analysis
+
+Use this skill when the source is release-shaped: GitHub releases, prerelease tags,
+OpenAI developer changelogs, app update notes, or a release-focused social post.
+
+This is a Decodex repository-development instruction surface, not an installable
+Decodex plugin skill.
+
+## Read Before Analysis
+
+- `docs/spec/release-delta.md`
+- `docs/spec/signal-entry.md`
+- `docs/spec/upstream-impact.md`
+- `docs/runbook/local-github-signal-workflow.md`
+- `dev/skills/codex-upstream-triage/SKILL.md`
+- `dev/skills/codex-code-analysis/SKILL.md`
+
+## Inputs
+
+- Release tag, changelog URL, or app update URL
+- Existing `release_delta/v1` artifact, when available
+- Existing Decodex signals that may explain the release delta
+- GitHub compare, commit, or PR evidence for any claim beyond the release headline
+
+This skill is an advisory reasoning pass. It does not define a new checked-in
+release-analysis artifact and does not replace deterministic `release_delta/v1`
+generation.
+
+## Release Reading Rules
+
+- Treat release and prerelease tags as reporting checkpoints over the commit/PR stream,
+  not as a separate higher-priority intake lane.
+- Treat release notes as discovery, not proof, when they are sparse.
+- Use GitHub compare data and PR mappings to explain what changed between stable and
+  prerelease tags.
+- Prefer already-published `signal_entry/v1` items when they match the compare commit
+  or PR evidence.
+- Do not imply a feature is broadly available when the source says alpha, beta,
+  rollout, platform-gated, or config-gated.
+- Do not write a release recap that only duplicates a release bot. Prefer a summary
+  built from accumulated Decodex signal, upstream-impact, and commit/PR analysis.
+
+## Release Rollup Path
+
+When the target is an OpenAI Codex release or prerelease:
+
+1. Refresh or read `release_delta/v1`.
+2. Select the top-level `stable_release` -> `prerelease` comparison unless the user
+   asks for a specific tag pair.
+3. Start from existing `signal_entry/v1`, `upstream_impact/v1`, and recent
+   commit/PR analyses that match the compare range.
+4. Use `compare.pr_numbers` and `compare.commit_shas` to find gaps that still need
+   code analysis.
+5. Group findings by reader value: useful now, important for Decodex Control Plane,
+   deprecated/removed behavior, and watch-only changes.
+6. Draft release or prerelease X reporting only after the summary is grounded in those
+   historical analyses.
+7. Refresh `release_delta/v1` after new signals are rendered so the homepage can map
+   the release window to tracked signals.
+
+## Analysis Modes
+
+Use exactly one primary mode:
+
+| Mode | Use when | Output |
+| --- | --- | --- |
+| `release_pulse` | The release headline is the story and evidence is thin. | Short awareness note or social draft. |
+| `delta_explainer` | Compare commits map to existing signals or clear PRs. | Refresh existing `release_delta/v1` and summarize the evidence. |
+| `operator_impact` | Release changes app-server, plugins, browser, MCP, permissions, sandbox, hooks, config, auth, or providers. | `upstream_impact/v1` plus possible follow-up issue. |
+| `watch_note` | The release is interesting but evidence is incomplete. | Watch note with caveats. |
+
+For sparse Codex prereleases, prefer `delta_explainer`, `operator_impact`, or a
+source-backed release rollup over `release_pulse`; the release version alone is rarely
+the useful story.
+
+## Style Lessons
+
+- Release-bot style is useful for speed: version, three bullets, source link.
+- Human analysis style is useful for value: what changes in a real workflow, why it
+  matters, what to try, and where the limit remains.
+- Decodex should prefer the human-analysis shape whenever source evidence supports it.
+
+## Output
+
+Return:
+
+- release source and timestamp
+- whether the release body is explanatory or sparse
+- compare or PR evidence used
+- matching Decodex signal slugs, if any
+- chosen mode
+- user-facing takeaway
+- Control Plane impact, if any
+- Publisher recommendation: no post, `release_pulse`, `practical_explainer`,
+  `operator_impact`, `release_rollup`, or `watch_note`
+
+Promote durable conclusions into existing artifacts only: `upstream_impact/v1`,
+`analysis_draft` plus rendered `signal_entry/v1`, refreshed `release_delta/v1`, or
+`social_post_draft/v1`.