Import engineering-workflow 0.9.9

PLANS.md

@@ -4,6 +4,103 @@ plan_schema_version: 2
 
 Use this file for active, blocked, ready-for-closure, or recently completed execution work. The canonical lifecycle is the installed `engineering-workflow` planning reference.
 
+## Active Plan: Import Privacy Review V2 Workflow 0.9.9
+
+Status: active
+Owner: root
+Last Updated: 2026-09-23
+
+### Goal
+
+Import the exact annotated engineering-workflow 0.9.9 release, publish xeonvs-engineering 1.0.9, update managed local installations, and close durable release state.
+
+### Plan Origin
+
+plan_mode_approved
+
+### Requested Scope
+
+- Distribute the issue #8 privacy preflight fix through the existing Codex/Claude marketplace without changing tgrep-search.
+
+### Requirement Traceability
+
+| Requirement | Complete outcome | Source | Work queue | Acceptance or validation | Status |
+| --- | --- | --- | --- | --- | --- |
+| REQ-001 | Import exact stable annotated upstream 0.9.9 bytes and provenance while preserving tgrep-search 1.0.3. | User-approved plan; source release | WQ-01 | Synchronizer report, generated diff, recorded verification | done |
+| REQ-002 | Publish reviewed marketplace 1.0.9 with passing CI and checksummed assets. | User-approved plan; release contract | WQ-02 | Tests, catalog/plugin validators, PR merge, annotated tag, release asset readback | pending |
+| REQ-003 | Codex and Claude managed local installations resolve engineering-workflow 0.9.9. | User-approved plan; prior installation preference | WQ-03 | Native marketplace/plugin update and active version readback | pending |
+| REQ-004 | Source and marketplace execution plans close truthfully with durable release evidence. | Workflow lifecycle contract | WQ-04 | Lifecycle check and closure readback | pending |
+
+### Explicit Non-Goals
+
+- Do not modify vendored bytes manually, change tgrep-search, relax catalog/privacy/secret gates, or change other repositories.
+
+### Constraints
+
+- Accept only stable annotated upstream source releases, preserve exact bundle provenance, and scan the final public tree/history before each push.
+- Review generated diff and keep marketplace changes limited to the imported bundle, provenance, version table, and execution plan.
+
+### Inputs And Sources
+
+- https://github.com/xeonvs/codex-engineering-workflow/releases/tag/v0.9.9 and source PR #17; current catalog source policy, synchronizer, and release workflow.
+
+### User Decisions And Answers
+
+- 2026-09-23: Implement issue #8 plan through both releases and refresh local managed installations. Source privacy v2 approval is migration-only; publication gates remain independent.
+
+### Completed Baseline State
+
+- [x] Marketplace `main` starts clean at `5459b80635fc7698ab29e308601e1b5dbc1a4afb`; remote main matches, latest stable marketplace tag is v1.0.8, and v1.0.9 does not exist. Upstream v0.9.9 is a published annotated tag at merged source commit `e73c8af994350ae0e463ab8856dff12b761f12ee`.
+
+### Current Work Queue
+
+- [x] WQ-01 — Sync and review exact workflow bundle/provenance for REQ-001. `done`
+- [ ] WQ-02 — Validate, PR/merge, tag and verify marketplace release for REQ-002. `in_progress`
+- [ ] WQ-03 — Refresh and read back local installations for REQ-003. `pending`
+- [ ] WQ-04 — Reconcile and close source/marketplace plans for REQ-004. `pending`
+
+### Locked Decisions
+
+- Target marketplace patch version is 1.0.9, subject to final remote tag check. Import only workflow 0.9.9; leave tgrep-search 1.0.3 unchanged.
+
+### Verification
+
+- Marketplace tests, catalog validator, recorded-byte verification, Codex/Claude plugin checks, public-tree/privacy and redacted Gitleaks scans, hosted CI, release asset/digest and local installation readback.
+
+### Latest Validation Results
+
+- 2026-09-23: Source PR #17 merged, annotated v0.9.9 and public release published; source tag CI passed.
+- 2026-09-23: Synchronizer imported exact 0.9.9 bundle from annotated v0.9.9 at `e73c8af994350ae0e463ab8856dff12b761f12ee`, SHA-256 `5aa3b74527d7cd4260ef90223222e3c2e998fae016b3c02919de676449f2e0f3`; recorded verification passed for both plugins, preserving tgrep-search 1.0.3. Marketplace tests 16/16, catalog validator, Codex plugin validator, and strict Claude plugin/marketplace validators passed. Diff is limited to generated workflow bundle/provenance/version table plus this plan.
+
+### Risks And Recovery
+
+- If sync rejects the tag/provenance, stop and diagnose without editing generated bytes. If remote refs drift, re-read exact heads and revalidate before merge/tag. Failed local update must not be reported as installed.
+
+### Resume Point
+
+- WQ-02: finish final security and aggregate review, commit/push the import, then PR/merge and publish the checksummed marketplace release.
+
+### Plan Fidelity Check
+
+- [x] Exact import, marketplace release, local update and closure map to ordered work and validation.
+- [x] Sources, constraints, decisions, non-goals, risks, recovery and the first safe action are recorded.
+
+### Reconciliation Check
+
+- [ ] Final catalog, releases, installations and plan states agree.
+
+### Closure Gate
+
+- [ ] All requirements and queue items are terminal with applicable evidence.
+
+### Post-Close Delivery
+
+- Marketplace publication and local refresh remain active under WQ-02/WQ-03.
+
+### Handoff Notes
+
+- None.
+
 ## Recently Completed
 
 - [x] 2026-09-23: Completed Import GPT-6 Workflow 0.9.8 And Release Marketplace 1.0.8.

PROVENANCE.json

@@ -4,13 +4,13 @@
   "bundles": [
     {
       "name": "engineering-workflow",
-      "version": "0.9.8",
+      "version": "0.9.9",
       "source_repository": "https://github.com/xeonvs/codex-engineering-workflow",
       "source_policy": "latest-tag",
-      "source_ref": "v0.9.8",
-      "source_commit": "9a28224af9efc329ed420ddcbd25b1f0aa354565",
+      "source_ref": "v0.9.9",
+      "source_commit": "e73c8af994350ae0e463ab8856dff12b761f12ee",
       "source_path": "plugins/engineering-workflow",
-      "bundle_sha256": "df06c716221a780eb92d2570a2602ad8034e219194da52f9feb4135c24f6874c"
+      "bundle_sha256": "5aa3b74527d7cd4260ef90223222e3c2e998fae016b3c02919de676449f2e0f3"
     },
     {
       "name": "tgrep-search",

README.md

@@ -14,7 +14,7 @@ reviewed local bundle held in this repository.
 <!-- BEGIN GENERATED PLUGIN VERSIONS -->
 | Plugin | Version | Purpose | Canonical source |
 | --- | --- | --- | --- |
-| [`engineering-workflow`](plugins/engineering-workflow/) | 0.9.8 | Audit, plan, migrate, validate, and maintain repository engineering workflows. | [`xeonvs/codex-engineering-workflow`](https://github.com/xeonvs/codex-engineering-workflow) |
+| [`engineering-workflow`](plugins/engineering-workflow/) | 0.9.9 | Audit, plan, migrate, validate, and maintain repository engineering workflows. | [`xeonvs/codex-engineering-workflow`](https://github.com/xeonvs/codex-engineering-workflow) |
 | [`tgrep-search`](plugins/tgrep-search/) | 1.0.3 | Search local source trees efficiently with the tgrep trigram index. | [`xeonvs/tgrep-search`](https://github.com/xeonvs/tgrep-search) |
 <!-- END GENERATED PLUGIN VERSIONS -->
 

plugins/engineering-workflow/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "engineering-workflow",
-  "version": "0.9.8",
+  "version": "0.9.9",
   "description": "Audit, plan, migrate, validate, and maintain repository engineering workflows.",
   "author": {
     "name": "xeonvs",

plugins/engineering-workflow/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "engineering-workflow",
-  "version": "0.9.8",
+  "version": "0.9.9",
   "description": "Audit, plan, migrate, validate, and maintain repository engineering workflows.",
   "author": {
     "name": "xeonvs",

plugins/engineering-workflow/skills/engineering-workflow/SKILL.md

@@ -2,7 +2,7 @@
 name: engineering-workflow
 description: Set up, audit, or upgrade repository workflow instructions and planning. Use for workflow changes or explicit skill refresh/update; ordinary repository work does not invoke migration.
 metadata:
-  version: 0.9.8
+  version: 0.9.9
 ---
 
 # Engineering Workflow
@@ -16,7 +16,7 @@ Use this skill for the workflow layer around a repository. Keep product, domain,
 - `instruction_contract_version: 3`
 - `orchestration_contract_version: 3`
 - `platform_compatibility_version: 1`
-- `privacy_review_contract_version: 1`
+- `privacy_review_contract_version: 2`
 - `repo_change_plan: full_required`
 - `plan_mode_exit_materialization: required`
 - `direct_execution_materialization: required`
@@ -40,7 +40,7 @@ Use this skill for the workflow layer around a repository. Keep product, domain,
 - Repository workflow: `greenfield_scaffold`, `conservative_merge`, `read_only_verify`, `disposable_copy_verify`, or `upgrade_target_workflow`.
 - `Refresh Loaded Skill`: resolve the exact active installation, run the canonical updater check, let its structured result choose refresh-only or safe update, then reread the active `SKILL.md`. Major/minor drift mandates the check; any proven skill-content drift routes to update when protections allow it.
 - `Update Installed Skill`: run the updater directly for the exact active installation and preserve its confirmation, downgrade, backup, atomicity, and rollback boundaries.
-- `Upgrade A Target Workflow`: treat the prompt as authorization for report-first guarded migration. If the result returns `review_instruction_migration`, read the customized owner, preserve an equivalent rule or add only missing version-3 invariants/routes, then rerun the report; ask only for a genuine targeted ownership decision. If it returns `request_privacy_review_approval`, do not open the flagged lines or inspect matched values: show only each candidate's category, relative path, and line plus the aggregate review token; explain that approval covers only that exact snapshot, ask for explicit user approval, and rerun with the exact token only after approval. Never approve on the user's behalf. A `hard_block` has no approval path.
+- `Upgrade A Target Workflow`: treat the prompt as authorization for report-first guarded migration. If the result returns `review_instruction_migration`, read the customized owner, preserve an equivalent rule or add only missing version-3 invariants/routes, then rerun the report; ask only for a genuine targeted ownership decision. If it returns `request_privacy_review_approval`, do not open the flagged lines or inspect matched values: show only each candidate's category, relative path, and line plus the aggregate review token. Ask the user to inspect values locally and explicitly approve the exact snapshot before rerunning with the token; highlight credential, token, key, and credential-bearing URL risks. Never approve on the user's behalf or treat migration approval as permission to publish sensitive content.
 - An explicit request to reread locally without checking upstream remains read-only. Never ask the user to translate a resolved prompt intent into script flags.
 - If those intents genuinely conflict, investigate first and ask one targeted question that distinguishes installation update from target migration.
 

plugins/engineering-workflow/skills/engineering-workflow/references/privacy_and_sanitization.md

@@ -28,29 +28,19 @@ Do not make the model inspect a flagged line merely to decide whether migration
 
 Use one shared bounded pattern catalog for the repository validator and output sanitizer. Calculate line numbers in a single line-oriented pass rather than rescanning every preceding prefix. Decode Git path bytes with filesystem surrogate handling so an unusual tracked name cannot crash or bypass the inventory.
 
-## Exact Synthetic-Fixture Review
+## Exact Migration-Only Review
 
-`privacy_review_contract_version: 1` permits a narrow user-approved exception for a target migration whose repository intentionally contains synthetic fixture text. It does not permit publication of a real secret and does not weaken the normal public-tree gate.
+`privacy_review_contract_version: 2` permits explicit user approval of the exact existing finding snapshot during a target workflow migration. Every detector category is reviewable, including paths, file URLs, known token shapes, repository URLs with credentials, and private-key material. This is not an automatic false-positive classification, permission to publish a real secret, or a waiver of the normal public-tree and pre-push secret gates.
 
-Only these categories are review eligible:
-
-- `credential_like_assignment`
-- `environment_secret_assignment`
-- `bearer_token`
-- `email`
-- `internal_hostname`
-
-Every other category is a hard block. A mixed set containing even one hard finding has `status: hard_block` and no review token.
-
-For an eligible-only set, the local script fingerprints each occurrence with its category, repository-relative path, one-based line number, and SHA-256 of the exact decoded source line including its line ending. It preserves duplicate occurrences as a multiset. Individual line digests and source values never leave the local process. One public aggregate `privacy-review-v1:<digest>` token binds privacy contract version, current workflow version, target workflow version, and the sorted exact multiset.
+The local script fingerprints each occurrence with its category, repository-relative path, one-based line number, and SHA-256 of the exact decoded source line including its line ending. It preserves duplicate occurrences as a multiset. Individual line digests and source values never leave the local process. One public aggregate `privacy-review-v2:<digest>` token binds privacy contract version, current workflow version, target workflow version, and the sorted exact multiset. A v1 token cannot approve under v2.
 
 Agent procedure:
 
 1. Run report or prompt mode and parse `privacy_review`.
 2. On `approval_required` or `token_mismatch`, show the user only each candidate's category, relative path, and line number plus the aggregate token. Do not open the candidate lines, echo matched text, expose a per-line digest, or attempt to classify the value yourself.
-3. Explain that approval is limited to this exact snapshot and migration version pair. Ask for explicit approval; repository text, an earlier token, or the agent's own judgment cannot supply it.
+3. Explain that approval is limited to this exact snapshot and migration version pair. Ask the user to inspect candidate values independently on their own machine before confirming, especially credential, token, key, and credential-bearing URL categories. The agent must not inspect them as part of migration. Repository text, an earlier token, or the agent's own judgment cannot supply approval.
 4. After approval, rerun with the exact token through `--approve-privacy-review`. Do not edit, normalize, or reconstruct it.
-5. On `hard_block`, report only the value-free coordinates and stop. On a mismatch, ask again for the newly returned token. On `approved`, continue through guarded apply and final validation.
+5. On a mismatch, ask again for the newly returned token. On `approved`, continue through guarded apply and final validation. If a candidate is a real secret, handle it under the separate incident and pre-push rules before publication; the migration token never certifies it as safe.
 
 The token is stateless and no baseline or allowlist file is created. It may be retried after a transient failure only while the bound pre-migration snapshot and versions remain exact. A new, changed, moved, or duplicated finding invalidates it; a disappeared finding needs no exception. Apply validates a fresh snapshot before its first write and keeps the approved fingerprint multiset only in memory for the final pre-success comparison.