diff --git a/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md b/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md new file mode 100644 index 000000000..bb84138f4 --- /dev/null +++ b/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md @@ -0,0 +1,196 @@ +--- +status: complete +priority: p2 +issue_id: "019" +tags: [manager, cms, jobs, cleanup] +dependencies: [] +--- + +# Remove legacy CMS notify UI and step + +## Problem Statement + +Before this cleanup, the branch still exposed legacy CMS notification concepts that were not part of the live enrichment flow: + +- a `cms_notify` workflow step name in manager job types and UI copy +- a `Notify CMS (Strapi)` checkbox in the old manual job form + +These implied that enrichment results were actively pushed back into Strapi CMS as a downstream completion step, but that is not how the current branch works. The durable job record is stored in Strapi, while generated artifacts are stored in Forge-managed artifact storage. Leaving those stale affordances in place created confusion about actual product behavior and made later CMS write-back planning harder because the UI already appeared to promise something we do not do. + +This cleanup also needed to distinguish between stale runtime code and forward-looking planning language. `cms_notify` was dead manager vocabulary. `cms_sync` appeared as planned terminology in docs, but it could not be removed from code unless a fresh audit confirmed it was only documentary and not part of a live execution path. + +Current state: + +- `cms_notify` and `notifyCms` have been removed from manager runtime code. +- `cms_sync` remains only in planning docs for future CMS write-back work. + +## Findings + +- Baseline discovery: [types/job.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts) included `cms_notify` in `WorkflowStepName` and `notifyCms` in `JobOptions`. +- Baseline discovery: [live-job-steps-table.tsx](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx) rendered the step description `Notifies downstream CMS integrations of completion.` +- Baseline discovery: [new-job-form.tsx](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx) showed a `Notify CMS (Strapi)` checkbox and posted `options.notifyCms`. +- Baseline discovery: `rg` over `apps/manager/src` found no live implementation path that actually performed a CMS notification step. The only remaining references were the type name, old form state, and step-table copy. +- Baseline discovery: [app/api/jobs/route.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/api/jobs/route.ts) did not accept `notifyCms`, which confirmed the checkbox was disconnected from the live jobs API contract. +- Baseline discovery: [workflow-steps.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/lib/workflow-steps.ts) and [videoEnrichment.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/workflows/videoEnrichment.ts) only created and ran `transcription`, `translation`, `chapters`, `metadata`, and `embeddings`. +- Baseline discovery: `rg` over manager, CMS, packages, roadmap, and plans found no runtime `cms_sync` implementation. `cms_sync` references were limited to planning docs for future CMS write-back work. +- [strapi-enrichment-job-content-type.md](/Users/o/.codex/worktrees/9f1b/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md) confirms the actual pattern: Strapi stores durable job state, not all enrichment outputs as downstream-notified content. + +## Proposed Solutions + +### Option 1: Remove the stale step and checkbox entirely + +**Approach:** Delete `cms_notify` and `notifyCms` from manager types and old form UI, and refresh any related copy/tests. + +**Pros:** + +- Aligns code and UI with current branch reality +- Reduces product confusion before any real CMS write-back feature exists +- Makes future CMS sync work start from a truthful baseline + +**Cons:** + +- Slightly narrows compatibility with older upstream VideoForge vocabulary +- May require updating snapshot tests or historical assumptions in docs + +**Effort:** 1-2 hours + +**Risk:** Low + +--- + +### Option 2: Keep the vocabulary but hide the UI affordance + +**Approach:** Remove the checkbox from the old form, but keep `cms_notify` in step/type unions as dormant compatibility scaffolding. + +**Pros:** + +- Smaller surface change +- Retains upstream vocabulary if needed later + +**Cons:** + +- Leaves misleading dead code and step descriptions in place +- Does not fully resolve the conceptual drift + +**Effort:** Under 1 hour + +**Risk:** Low + +--- + +### Option 3: Keep both and document them as future-facing + +**Approach:** Leave the checkbox and step name, but add explanatory copy/docs that the path is not currently wired. + +**Pros:** + +- Minimal code churn +- Preserves possible future intent + +**Cons:** + +- Continues to expose inaccurate UX +- Increases operator confusion +- Harder to distinguish real CMS sync work later + +**Effort:** 1 hour + +**Risk:** Medium + +## Recommended Action + +Remove the stale `cms_notify` runtime vocabulary from manager now: delete the dead checkbox, request payload field, type union member, and step-table copy, then update any affected tests. Do not remove planning-doc references to `cms_sync`; instead, verify again during implementation that `cms_sync` still has no runtime callers and only remove code-level traces that are actually unused. + +## Technical Details + +**Affected files:** + +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts) +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx) +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx) +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/api/jobs/route.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/app/api/jobs/route.ts) +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/lib/workflow-steps.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/lib/workflow-steps.ts) +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/workflows/videoEnrichment.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/workflows/videoEnrichment.ts) + +**Related components:** + +- job detail step rendering +- legacy manual job creation UI +- any manager tests that assert the full workflow step vocabulary + +**Database changes (if any):** + +- Migration needed? No +- New columns/tables? No + +## Resources + +- **Solution doc:** [/Users/o/.codex/worktrees/9f1b/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md](/Users/o/.codex/worktrees/9f1b/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md) +- **Related plan:** [/Users/o/.codex/worktrees/9f1b/forge/docs/plans/2026-04-09-feat-sync-enrichment-results-into-cms-models-plan.md](/Users/o/.codex/worktrees/9f1b/forge/docs/plans/2026-04-09-feat-sync-enrichment-results-into-cms-models-plan.md) + +## Acceptance Criteria + +- [x] `cms_notify` is removed from the active manager workflow vocabulary unless a real implementation exists in the same change. +- [x] `notifyCms` is removed from the old manual job form and request payload. +- [x] Step-table copy no longer claims a downstream CMS notification step that does not exist. +- [x] A fresh search confirms there is still no runtime `cms_sync` implementation before removing any similarly named code. +- [x] Any affected manager tests are updated and pass. +- [x] Manager UI remains truthful about what is stored in Strapi versus artifact storage. + +## Work Log + +### 2026-04-09 - Initial Discovery + +**By:** Codex + +**Actions:** + +- Audited manager and CMS code paths for `cms_notify` and `notifyCms` +- Confirmed remaining references are stale type/UI affordances only +- Verified current branch behavior stores durable job state in Strapi and artifacts outside Strapi +- Drafted cleanup options and acceptance criteria + +**Learnings:** + +- The old manual job form still exposes upstream VideoForge-era options that are not part of the live enrich flow +- This cleanup is mostly a truthfulness/UX alignment task, not a behavior migration + +### 2026-04-10 - Scope Refresh + +**By:** Codex + +**Actions:** + +- Re-audited manager runtime code, workflow setup, and jobs API for `cms_notify`, `notifyCms`, and `cms_sync` +- Confirmed `notifyCms` is not accepted by the live jobs API +- Confirmed the executed workflow still only runs transcription, translation, chapters, metadata, and embeddings +- Confirmed `cms_sync` currently appears only in planning docs, not in runtime code +- Promoted this todo to `ready` based on explicit user approval to perform the cleanup + +**Learnings:** + +- `cms_notify` is dead runtime vocabulary and safe cleanup territory once tests are updated +- `cms_sync` is currently a future-facing planning term, so documentary references should not be removed as part of code cleanup unless the related plan is intentionally being revised + +### 2026-04-10 - Implementation Complete + +**By:** Codex + +**Actions:** + +- Removed the unused legacy manager job form file that still posted `notifyCms` +- Removed `cms_notify` from the manager workflow step union and job-step UI copy +- Verified no runtime `cms_notify`, `notifyCms`, `cms_sync`, or `content_sync` references remain under manager, CMS, or packages +- Installed workspace dependencies with `pnpm install --frozen-lockfile` so validation could run in this worktree +- Ran `pnpm --filter @forge/manager typecheck` +- Ran `pnpm --filter @forge/manager lint` +- Ran `pnpm --filter @forge/manager test` + +**Learnings:** + +- The only remaining `cms_sync` references are plan-level documentation for future CMS write-back work +- The legacy manual job form was fully unused in the current manager app, so deleting it was lower risk than trying to preserve a stale incompatible API shape + +## Notes + +- If future work adds real CMS write-back, it should return as a newly planned feature with explicit behavior and audit trails rather than reusing stale dormant affordances by accident. diff --git a/.context/compound-engineering/todos/019-pending-p2-remove-legacy-cms-notify-ui-and-step.md b/.context/compound-engineering/todos/019-pending-p2-remove-legacy-cms-notify-ui-and-step.md deleted file mode 100644 index 14d9904c3..000000000 --- a/.context/compound-engineering/todos/019-pending-p2-remove-legacy-cms-notify-ui-and-step.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -status: pending -priority: p2 -issue_id: "019" -tags: [manager, cms, jobs, cleanup] -dependencies: [] ---- - -# Remove legacy CMS notify UI and step - -## Problem Statement - -The branch still exposes legacy CMS notification concepts that are not part of the live enrichment flow: - -- a `cms_notify` workflow step name in manager job types and UI copy -- a `Notify CMS (Strapi)` checkbox in the old manual job form - -These imply that enrichment results are actively pushed back into Strapi CMS as a downstream completion step, but that is not how the current branch works. The durable job record is stored in Strapi, while generated artifacts are stored in Forge-managed artifact storage. Leaving these stale affordances in place creates confusion about actual product behavior and makes later CMS write-back planning harder because the UI already appears to promise something we do not do. - -## Findings - -- [types/job.ts](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/types/job.ts) still includes `cms_notify` in `WorkflowStepName` and `notifyCms` in `JobOptions`. -- [live-job-steps-table.tsx](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx) still renders the step description `Notifies downstream CMS integrations of completion.` -- [new-job-form.tsx](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx) still shows a `Notify CMS (Strapi)` checkbox and posts `options.notifyCms`. -- `rg` over `apps/manager/src` found no live implementation path that actually performs a CMS notification step. The only remaining references are the type name, old form state, and step-table copy. -- [strapi-enrichment-job-content-type.md](/Users/o/.codex/worktrees/1ec2/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md) confirms the actual pattern: Strapi stores durable job state, not all enrichment outputs as downstream-notified content. - -## Proposed Solutions - -### Option 1: Remove the stale step and checkbox entirely - -**Approach:** Delete `cms_notify` and `notifyCms` from manager types and old form UI, and refresh any related copy/tests. - -**Pros:** - -- Aligns code and UI with current branch reality -- Reduces product confusion before any real CMS write-back feature exists -- Makes future CMS sync work start from a truthful baseline - -**Cons:** - -- Slightly narrows compatibility with older upstream VideoForge vocabulary -- May require updating snapshot tests or historical assumptions in docs - -**Effort:** 1-2 hours - -**Risk:** Low - ---- - -### Option 2: Keep the vocabulary but hide the UI affordance - -**Approach:** Remove the checkbox from the old form, but keep `cms_notify` in step/type unions as dormant compatibility scaffolding. - -**Pros:** - -- Smaller surface change -- Retains upstream vocabulary if needed later - -**Cons:** - -- Leaves misleading dead code and step descriptions in place -- Does not fully resolve the conceptual drift - -**Effort:** Under 1 hour - -**Risk:** Low - ---- - -### Option 3: Keep both and document them as future-facing - -**Approach:** Leave the checkbox and step name, but add explanatory copy/docs that the path is not currently wired. - -**Pros:** - -- Minimal code churn -- Preserves possible future intent - -**Cons:** - -- Continues to expose inaccurate UX -- Increases operator confusion -- Harder to distinguish real CMS sync work later - -**Effort:** 1 hour - -**Risk:** Medium - -## Recommended Action - -**To be filled during triage.** Preferred direction is Option 1: remove both the stale workflow name and the old form checkbox, then update any affected tests/docs so the manager UI only reflects real supported flows. - -## Technical Details - -**Affected files:** - -- [/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/types/job.ts](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/types/job.ts) -- [/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/features/jobs/live-job-steps-table.tsx) -- [/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx](/Users/o/.codex/worktrees/1ec2/forge/apps/manager/src/app/dashboard/jobs/new-job-form.tsx) - -**Related components:** - -- job detail step rendering -- legacy manual job creation UI -- any manager tests that assert the full workflow step vocabulary - -**Database changes (if any):** - -- Migration needed? No -- New columns/tables? No - -## Resources - -- **Solution doc:** [/Users/o/.codex/worktrees/1ec2/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md](/Users/o/.codex/worktrees/1ec2/forge/docs/solutions/cms/strapi-enrichment-job-content-type.md) -- **Related plan:** [/Users/o/.codex/worktrees/1ec2/forge/docs/plans/2026-04-09-feat-mux-sync-for-enrichment-outputs-plan.md](/Users/o/.codex/worktrees/1ec2/forge/docs/plans/2026-04-09-feat-mux-sync-for-enrichment-outputs-plan.md) - -## Acceptance Criteria - -- [ ] `cms_notify` is removed from the active manager workflow vocabulary unless a real implementation exists in the same change. -- [ ] `notifyCms` is removed from the old manual job form and request payload. -- [ ] Step-table copy no longer claims a downstream CMS notification step that does not exist. -- [ ] Any affected manager tests are updated and pass. -- [ ] Manager UI remains truthful about what is stored in Strapi versus artifact storage. - -## Work Log - -### 2026-04-09 - Initial Discovery - -**By:** Codex - -**Actions:** - -- Audited manager and CMS code paths for `cms_notify` and `notifyCms` -- Confirmed remaining references are stale type/UI affordances only -- Verified current branch behavior stores durable job state in Strapi and artifacts outside Strapi -- Drafted cleanup options and acceptance criteria - -**Learnings:** - -- The old manual job form still exposes upstream VideoForge-era options that are not part of the live enrich flow -- This cleanup is mostly a truthfulness/UX alignment task, not a behavior migration - -## Notes - -- If future work adds real CMS write-back, it should return as a newly planned feature with explicit behavior and audit trails rather than reusing stale dormant affordances by accident. diff --git a/.context/compound-engineering/todos/022-complete-p3-fix-manager-job-type-comment-after-cms-notify-removal.md b/.context/compound-engineering/todos/022-complete-p3-fix-manager-job-type-comment-after-cms-notify-removal.md new file mode 100644 index 000000000..708cae268 --- /dev/null +++ b/.context/compound-engineering/todos/022-complete-p3-fix-manager-job-type-comment-after-cms-notify-removal.md @@ -0,0 +1,125 @@ +--- +status: complete +priority: p3 +issue_id: "022" +tags: [code-review, manager, typescript, quality] +dependencies: [] +--- + +# Fix manager job type comment after cms_notify removal + +## Problem Statement + +The header comment in `apps/manager/src/types/job.ts` no longer matches the code beneath it after the `cms_notify` cleanup. + +It still says the job types were copied "verbatim" from the original VideoForge repo and that "the full union is kept," but this branch now intentionally removes `cms_notify` and `notifyCms`. Leaving that provenance comment stale makes this core type file less trustworthy and can mislead future maintainers about which compatibility constraints are still real. + +## Findings + +- [apps/manager/src/types/job.ts:1](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts#L1) still says the types were copied "verbatim" and that "the full union is kept." +- The same file now omits `cms_notify` from `WorkflowStepName` and removes `notifyCms` from `JobOptions`, so the comment overstates current compatibility. +- This came up during multi-agent review of the `cms_notify` cleanup as a documentation/trustworthiness issue rather than a runtime bug. + +## Proposed Solutions + +### Option 1: Rewrite the header comment to describe current reality + +**Approach:** Update the comment to say the file started from upstream VideoForge types but now preserves only the compatibility vocabulary still intentionally supported in Forge. + +**Pros:** + +- Makes the file self-consistent +- Low effort, low risk +- Helps future maintainers understand intentional divergence + +**Cons:** + +- Requires deciding how much historical detail belongs in a source comment + +**Effort:** Under 30 minutes + +**Risk:** Low + +--- + +### Option 2: Remove the provenance comment entirely + +**Approach:** Delete the misleading header comment instead of maintaining historical context inline. + +**Pros:** + +- Eliminates drift risk +- Keeps the type file terse + +**Cons:** + +- Loses useful origin/context for future cleanup work + +**Effort:** Under 15 minutes + +**Risk:** Low + +## Recommended Action + +Rewrite the header comment in `apps/manager/src/types/job.ts` so it describes the current Forge compatibility surface instead of claiming verbatim parity with upstream VideoForge. + +## Technical Details + +**Affected files:** + +- [/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts](/Users/o/.codex/worktrees/9f1b/forge/apps/manager/src/types/job.ts) + +**Related components:** + +- manager job read model types +- workflow-step compatibility vocabulary + +**Database changes (if any):** + +- Migration needed? No +- New columns/tables? No + +## Resources + +- **Related cleanup todo:** [/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md](/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md) + +## Acceptance Criteria + +- [x] The header comment in `apps/manager/src/types/job.ts` no longer claims the types are copied verbatim if they are not. +- [x] The comment accurately describes the intentional compatibility surface that remains in Forge. +- [x] No behavior or type signatures change as part of the comment-only cleanup. + +## Work Log + +### 2026-04-10 - Review Finding Created + +**By:** Codex + +**Actions:** + +- Reviewed the `cms_notify` cleanup diff with parallel review agents +- Identified a stale provenance comment in `apps/manager/src/types/job.ts` +- Captured the issue as a durable review todo + +**Learnings:** + +- Small cleanup diffs can still leave behind misleading historical comments +- Source comments in shared type files need the same maintenance bar as the code they describe + +### 2026-04-10 - Implementation Complete + +**By:** Codex + +**Actions:** + +- Updated the `apps/manager/src/types/job.ts` header comment to describe the adapted Forge type surface instead of claiming verbatim upstream parity +- Kept the change comment-only with no type or behavior changes +- Re-ran manager validation alongside the related documentation cleanup + +**Learnings:** + +- A short provenance comment is still useful here, but it needs to describe intentional divergence explicitly + +## Notes + +- This is a P3 trustworthiness/documentation issue, not a runtime regression. diff --git a/.context/compound-engineering/todos/023-complete-p3-reconcile-completed-cms-notify-todo-narrative.md b/.context/compound-engineering/todos/023-complete-p3-reconcile-completed-cms-notify-todo-narrative.md new file mode 100644 index 000000000..42c9f81e4 --- /dev/null +++ b/.context/compound-engineering/todos/023-complete-p3-reconcile-completed-cms-notify-todo-narrative.md @@ -0,0 +1,126 @@ +--- +status: complete +priority: p3 +issue_id: "023" +tags: [code-review, todos, documentation, quality] +dependencies: [] +--- + +# Reconcile completed cms_notify todo narrative + +## Problem Statement + +The completed cleanup todo for `cms_notify` is internally inconsistent. + +Its status and acceptance criteria say the work is complete, but the earlier Findings section still speaks in present tense as if `cms_notify` and `notifyCms` are still in the codebase. That makes the durable artifact confusing to read later and weakens confidence in the todo history. + +## Findings + +- [019-complete-p2-remove-legacy-cms-notify-ui-and-step.md:2](/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md#L2) marks the todo `status: complete`. +- [019-complete-p2-remove-legacy-cms-notify-ui-and-step.md:128](/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md#L128) shows all acceptance criteria checked off. +- Earlier sections such as the Findings block still describe `cms_notify` and `notifyCms` as currently present, without framing that text as pre-fix discovery context. +- This surfaced during review as a documentation consistency issue in the durable todo artifact. + +## Proposed Solutions + +### Option 1: Reframe the existing findings as baseline discovery + +**Approach:** Keep the historical findings, but explicitly label them as pre-fix state and add a short current-state summary after implementation. + +**Pros:** + +- Preserves the investigative history +- Makes the completed todo internally consistent +- Best fit for a durable work log artifact + +**Cons:** + +- Slightly more editing than a simple wording pass + +**Effort:** Under 30 minutes + +**Risk:** Low + +--- + +### Option 2: Rewrite the Findings section into past tense + +**Approach:** Convert the present-tense statements into "before this fix" wording without adding a separate current-state summary. + +**Pros:** + +- Very small edit +- Resolves the direct contradiction + +**Cons:** + +- Leaves less explicit separation between baseline and completed state + +**Effort:** Under 15 minutes + +**Risk:** Low + +## Recommended Action + +Reframe the completed `cms_notify` cleanup todo so it clearly distinguishes pre-fix baseline findings from the current completed state, while preserving the investigation history. + +## Technical Details + +**Affected files:** + +- [/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md](/Users/o/.codex/worktrees/9f1b/forge/.context/compound-engineering/todos/019-complete-p2-remove-legacy-cms-notify-ui-and-step.md) + +**Related components:** + +- durable file-based todo history +- review artifact readability + +**Database changes (if any):** + +- Migration needed? No +- New columns/tables? No + +## Resources + +- **Related review scope:** current uncommitted `cms_notify` cleanup diff in `/Users/o/.codex/worktrees/9f1b/forge` + +## Acceptance Criteria + +- [x] The completed todo clearly distinguishes pre-fix findings from current state. +- [x] Readers can understand why the todo is complete without reading contradictory present-tense statements. +- [x] Historical investigation detail is preserved or intentionally simplified. + +## Work Log + +### 2026-04-10 - Review Finding Created + +**By:** Codex + +**Actions:** + +- Reviewed the completed `cms_notify` cleanup todo as part of a multi-agent code review +- Identified internal inconsistency between the todo status and the narrative sections +- Captured the documentation issue as a durable review todo + +**Learnings:** + +- Completed todos benefit from a short current-state framing, especially when they preserve pre-fix findings +- Review quality applies to process artifacts too, not just runtime code + +### 2026-04-10 - Implementation Complete + +**By:** Codex + +**Actions:** + +- Reframed the completed `cms_notify` cleanup todo as baseline discovery rather than current state +- Added a short current-state summary so the artifact now matches its `complete` status and checked acceptance criteria +- Kept the historical investigation details intact for future readers + +**Learnings:** + +- Completed durable todos read much better when they separate baseline findings from post-fix state explicitly + +## Notes + +- This is a P3 documentation/readability issue in the durable artifact, not a product behavior problem. diff --git a/apps/manager/src/app/dashboard/jobs/new-job-form.tsx b/apps/manager/src/app/dashboard/jobs/new-job-form.tsx deleted file mode 100644 index 0b9067e3e..000000000 --- a/apps/manager/src/app/dashboard/jobs/new-job-form.tsx +++ /dev/null @@ -1,168 +0,0 @@ -"use client" - -import React from "react" -import { useState } from "react" - -type RequestStatus = - | { type: "idle" } - | { type: "success"; message: string; jobId: string } - | { type: "error"; message: string } - -export function parseLanguageInput(value: string): string[] { - return [ - ...new Set( - value - .split(",") - .map((lang) => lang.trim()) - .filter(Boolean), - ), - ] -} - -export function NewJobForm() { - const [muxAssetId, setMuxAssetId] = useState("sample-mux-asset") - const [languages, setLanguages] = useState("es,fr") - const [generateVoiceover, setGenerateVoiceover] = useState(false) - const [uploadMux, setUploadMux] = useState(false) - const [notifyCms, setNotifyCms] = useState(false) - const [isSubmitting, setIsSubmitting] = useState(false) - const [status, setStatus] = useState({ type: "idle" }) - - const canSubmit = muxAssetId.trim().length > 0 && !isSubmitting - - async function onSubmit(event: React.FormEvent) { - event.preventDefault() - if (!muxAssetId.trim()) { - setStatus({ type: "error", message: "Mux Asset ID is required." }) - return - } - - setIsSubmitting(true) - setStatus({ type: "idle" }) - - try { - const response = await fetch("/api/jobs", { - method: "POST", - headers: { - "Content-Type": "application/json", - }, - body: JSON.stringify({ - muxAssetId: muxAssetId.trim(), - languages: parseLanguageInput(languages), - options: { - generateVoiceover, - uploadMux, - notifyCms, - }, - }), - }) - - const json = (await response.json()) as { - jobId?: string - error?: string - details?: string - code?: string - } - - if (!response.ok || !json.jobId) { - const message = [json.error, json.details, json.code] - .filter((value): value is string => Boolean(value && value.trim())) - .join(" | ") - throw new Error(message || "Failed to create job.") - } - - setStatus({ - type: "success", - jobId: json.jobId, - message: `Job ${json.jobId} created. Refresh to see updates.`, - }) - } catch (error) { - const message = - error instanceof Error ? error.message : "Failed to create job." - setStatus({ type: "error", message }) - } finally { - setIsSubmitting(false) - } - } - - return ( -
-
-

Create Enrichment Job

-
- -
- - -
- -
- - - -
- -
- -
- - {status.type !== "idle" && ( -

- {status.message}{" "} - {status.type === "success" ? ( - Open job - ) : null} -

- )} -
- ) -} diff --git a/apps/manager/src/features/jobs/live-job-steps-table.tsx b/apps/manager/src/features/jobs/live-job-steps-table.tsx index 05591b7c1..9e0d4ff93 100644 --- a/apps/manager/src/features/jobs/live-job-steps-table.tsx +++ b/apps/manager/src/features/jobs/live-job-steps-table.tsx @@ -50,7 +50,6 @@ const STEP_DESCRIPTION_BY_NAME: Record = { voiceover: "Synthesizes voiceover audio from generated text.", artifact_upload: "Uploads generated artifacts and writes the manifest.", mux_upload: "Publishes output assets to Mux for playback.", - cms_notify: "Notifies downstream CMS integrations of completion.", } function formatDuration(startedAt?: string, finishedAt?: string): string { @@ -105,7 +104,6 @@ function getStepLabelIcon(stepName: WorkflowStepName): LucideIcon { return FileAudio2 case "artifact_upload": case "mux_upload": - case "cms_notify": return FileJson2 default: return FileJson2 diff --git a/apps/manager/src/types/job.ts b/apps/manager/src/types/job.ts index 392039dbf..636147a11 100644 --- a/apps/manager/src/types/job.ts +++ b/apps/manager/src/types/job.ts @@ -1,8 +1,8 @@ -// Job types — copied verbatim from the original VideoForge repo. +// Job types — adapted from the original VideoForge repo. // Forge extension: muxPlaybackId added to JobRecord (stored at job creation). -// Forge uses only 5 of the 12 workflow steps (transcription, translation, -// chapters, metadata, embeddings) but the full union is kept so the original -// UI components compile unchanged. +// Forge executes only 5 workflow steps (transcription, translation, chapters, +// metadata, embeddings), but it still keeps the remaining intentionally +// supported legacy step vocabulary needed by existing manager UI components. export type JobStatus = "pending" | "running" | "completed" | "failed" @@ -25,12 +25,10 @@ export type WorkflowStepName = | "voiceover" | "artifact_upload" | "mux_upload" - | "cms_notify" export interface JobOptions { generateVoiceover?: boolean uploadMux?: boolean - notifyCms?: boolean } export type TranslationLanguageResult = {