docs(ai-docs): task refactor migration — task list & component layer (PR 4/4)#648
docs(ai-docs): task refactor migration — task list & component layer (PR 4/4)#648akulakum wants to merge 5 commits intowebex:nextfrom
Conversation
Add planning and reference documentation: - 011: Execution plan (10-milestone spec-first implementation plan) - 012: Task lifecycle flows (14 end-to-end scenarios, old vs new code paths) - 013: File inventory (25 files referencing old control names/types, cross-reference matrix) Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 708abfdacc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### M1: Types & Constants Alignment (1-2 days) | ||
|
|
||
| **Ref:** [009-types-and-constants-migration.md](./009-types-and-constants-migration.md) |
There was a problem hiding this comment.
Replace dead migration-doc references with valid targets
This execution plan points to prerequisite docs such as 009-types-and-constants-migration.md, but those targets are not present under ai-docs/migration in this tree (only 011–013 exist), so the milestone references are not navigable. Because each milestone depends on those linked specs, these broken links make the plan hard to execute and easy to misinterpret until the missing docs are added or the links are corrected.
Useful? React with 👍 / 👎.
| | cc-components types | 1 (central type file) | 0 | | ||
| | cc-components utils | 2 | 3+ (unaffected) | | ||
| | cc-components components | 4 | 8+ (unaffected) | | ||
| | Store | 3 | 1 (`store.ts`) | |
There was a problem hiding this comment.
Include store.types.ts in the definitive migration inventory
The document claims to be a definitive checklist of all old-control/state-flag references, but the Store summary omits store/src/store.types.ts, which still declares the legacy isDeclineButtonEnabled field used by IStore. If migration work follows this checklist as written, engineers can remove the runtime field from store.ts and miss the interface cleanup, leading to avoidable type breakage and an incomplete migration.
Useful? React with 👍 / 👎.
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d7d3d3264d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| | # | File | Old References | Migration Doc | | ||
| |---|------|---------------|--------------| | ||
| | 1 | `task/src/Utils/task-util.ts` | `getControlsVisibility()` — the entire function (~650 lines). Computes all 22 controls + 7 state flags. Calls `getConsultStatus`, `findHoldStatus`, `getIsConferenceInProgress`, etc. | [Doc 002](./002-ui-controls-migration.md) | |
There was a problem hiding this comment.
Replace missing migration-doc links in the inventory
This inventory is framed as the definitive migration checklist, but its per-file references point to docs like ./002-ui-controls-migration.md and ./010-component-layer-migration.md that do not exist in ai-docs/migration in this tree (only 011–013 are present), so readers cannot follow the linked implementation guidance. That makes the checklist non-actionable until these links are corrected or the missing docs are added.
Useful? React with 👍 / 👎.
| | cc-components types | 1 (central type file) | 0 | | ||
| | cc-components utils | 2 | 3+ (unaffected) | | ||
| | cc-components components | 4 | 8+ (unaffected) | | ||
| | Store | 3 | 1 (`store.ts`) | |
There was a problem hiding this comment.
Mark store.ts consistently as migration-required
The summary table classifies store.ts as an unaffected Store file, but later in the same document store/src/store.ts is explicitly listed as containing legacy migration targets (refreshTaskList(), isDeclineButtonEnabled). This contradiction in the top-level rollup can cause migration work to skip a file that the detailed plan says must be updated.
Useful? React with 👍 / 👎.
Move planning & reference migration docs to packages/contact-center/ai-docs/migration/. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 021b370718
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Purpose | ||
|
|
||
| This is the definitive inventory of **every file** in CC Widgets that references old task control names, state flags, or the `ControlVisibility` type. Use this as a checklist during migration to ensure nothing is missed. |
There was a problem hiding this comment.
Include omitted component files in the definitive inventory
This file declares itself the definitive list of every legacy-control reference, but it misses at least cc-components/src/components/task/IncomingTask/incoming-task.tsx and cc-components/src/components/task/TaskList/task-list.tsx, both of which still use legacy flags (isBrowser/isDeclineButtonEnabled) and pass them through migration-sensitive paths. I verified this with rg over packages/contact-center/cc-components/src/components/task, so following this checklist as written can leave required migrations incomplete.
Useful? React with 👍 / 👎.
| --- | ||
|
|
||
| _Created: 2026-03-09_ | ||
| _Parent: [001-migration-overview.md](./001-migration-overview.md)_ |
There was a problem hiding this comment.
Fix the broken parent link for the lifecycle flow doc
The parent reference points to ./001-migration-overview.md, but that target is not present in packages/contact-center/ai-docs/migration in this revision, so readers cannot navigate to the upstream overview from this document. This breaks the intended migration-doc chain and makes the flow reference harder to use.
Useful? React with 👍 / 👎.
Not a task-refactor change — keep migration docs scoped to SDK state machine migration only. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05808a1f8f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | # | File | Old References | Migration Doc | | ||
| |---|------|---------------|--------------| | ||
| | 18 | `store/src/constants.ts` | `TASK_STATE_CONSULT`, `TASK_STATE_CONSULTING`, `CONSULT_STATE_INITIATED`, `CONSULT_STATE_COMPLETED`, etc. — used by `getConsultStatus()` | [Doc 009](./009-types-and-constants-migration.md) | | ||
| | 19 | `store/src/store.ts` | `refreshTaskList()` method, `isDeclineButtonEnabled` observable | [Doc 003](./003-store-event-wiring-migration.md) | |
There was a problem hiding this comment.
Fix store.ts refreshTaskList reference
This inventory row says store/src/store.ts contains refreshTaskList(), but that method is implemented in store/src/storeEventsWrapper.ts (and store.ts only carries the isDeclineButtonEnabled field). Because this document is positioned as the migration checklist, this mislocation can send implementers to the wrong file and leave the actual event-wiring cleanup in storeEventsWrapper.ts incomplete.
Useful? React with 👍 / 👎.
…and component-layer Removed 011-execution-plan, 012-task-lifecycle-flows, 013-file-inventory. Added task-list-migration.md and component-layer-migration.md (moved from PR 3). Added ControlVisibility deletion details to component doc. Made-with: Cursor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a2d7be4a2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| <div className="call-control"> | ||
| {controls.hold.isVisible && ( | ||
| <Button onClick={() => onToggleHold(!controls.hold.isEnabled)} disabled={!controls.hold.isEnabled}> |
There was a problem hiding this comment.
Derive hold toggle from task hold state, not control enabled
The proposed migrated snippet calls onToggleHold(!controls.hold.isEnabled), but isEnabled is an actionability flag, not the current hold state; this can invert hold/resume behavior (e.g., enabled controls would always pass false) and directly conflicts with the later guidance in this same doc that isHeld must come from findHoldStatus(...). If implementers follow this example, they can ship incorrect hold handling in the migrated CallControl flow.
Useful? React with 👍 / 👎.
| | `task/src/helper.ts` (`useTaskList`) | Remove `isBrowser`, use per-task `uiControls` for accept/decline | | ||
| | `task/src/TaskList/index.tsx` | Remove `isBrowser` prop pass-through | | ||
| | `cc-components/.../TaskList/task-list.tsx` | Use `task.uiControls.accept/decline` per task | | ||
| | `cc-components/.../Task/task.utils.ts` | Update task data extraction if status source changes | |
There was a problem hiding this comment.
Point TaskList status migration to the actual extraction file
This migration checklist sends status-related updates to Task/task.utils.ts, but current TaskList status extraction is implemented in TaskList/task-list.utils.ts (task.data.interaction.state and displayState), and TaskList paths do not call getTaskStatus(). Following this plan will focus work on the wrong utility and can leave the real TaskList status logic unmigrated.
Useful? React with 👍 / 👎.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a2d7be4a2d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| <div className="call-control"> | ||
| {controls.hold.isVisible && ( | ||
| <Button onClick={() => onToggleHold(!controls.hold.isEnabled)} disabled={!controls.hold.isEnabled}> |
There was a problem hiding this comment.
Use hold state instead of button enabled flag for toggling
This example drives onToggleHold from !controls.hold.isEnabled, but isEnabled represents whether the UI action is currently allowed, not whether the call is already held. If implementers follow this snippet, hold/resume behavior will flip incorrectly in states where hold is temporarily disabled (for example consult/transition states), which can produce the wrong action request; the toggle should be based on actual hold state derived from task data.
Useful? React with 👍 / 👎.
|
|
||
| --- | ||
|
|
||
| _Parent: [migration-overview.md](./migration-overview.md)_ |
There was a problem hiding this comment.
Link parent reference to an existing migration overview file
This footer points to ./migration-overview.md, but there is no migration-overview.md in packages/contact-center/ai-docs/migration (or elsewhere in packages/contact-center/ai-docs), so the navigation link is broken in rendered docs. Because this same parent link is used in both new migration docs, readers cannot reach the intended overview unless the target file is added or the link is corrected.
Useful? React with 👍 / 👎.
COMPLETES #https://jira-eng-sjc12.cisco.com/jira/browse/CAI-7714
This pull request addresses
This is PR 4 of 4 in the task refactor migration documentation series. It covers the task list widget and component layer (
cc-components) migration — the presentational React components that receive control visibility as props.by making the following changes
Added 2 migration documents under
packages/contact-center/ai-docs/migration/:task-list-migration.md: Updates per-task accept/decline rendering to use
task.uiControlsinstead of deriving fromdeviceType:isBrowserprop pass-throughcomponent-layer-migration.md: Covers
cc-componentspresentational changes:ControlVisibilityinterface deletion and replacement withTaskUIControlsbuildCallControlButtons(): 20+ old control references mapped to new namescreateConsultButtons(): consult button builder migrationcall-control.tsxandcall-control-consult.tsx: props interface changesCallControlCAD: removesdeviceType,featureFlags,conferenceEnabled(retainsagentId)isHeldderivation fromfindHoldStatus(task, 'mainCall', agentId)(not fromcontrols.hold)Removed 3 planning/reference documents (superseded by consolidated overview in PR 1):
011-execution-plan.md012-task-lifecycle-flows-old-vs-new.md013-file-inventory-old-control-references.mdCC SDK Task-Refactor Branch Reference
Change Type
Related PRs
The following scenarios were tested
The GAI Coding Policy And Copyright Annotation Best Practices
Checklist before merging