How our shared design reached Tasks

Return to How the knowledge connects

Tasks, our product for scheduled work, was built from the shared design system we already had. I sent back one detail, a resize handle inside the instructions field, and my agents corrected the shared text field, published it and carried it into Tasks. A live check on October 20 showed the field growing with the text.

Record reviewed October 20, 2026. The work described here was delivered during October 2026. The full retained delivery review was completed on October 18; the focused live field check below was repeated on October 20.

Tasks gives people and agents a place to keep instructions, schedules and the history of scheduled work. Its browser interface uses the same shared navigation, list and detail panes, headers, account menu, controls and theme used in Cortex.

The agents building Tasks used those existing components. They connected them to the Tasks API and implemented the behavior specific to tasks, including editing instructions, changing schedules and distinguishing completion of one run from ending a recurring task.

You can inspect the shared design system and read what Tasks does. The working app requires sign-in.

After the first review, I noticed a resize handle inside the instructions field in the New task dialog. I wanted the field to grow with the writing without putting that handle in the middle of the form.

The earlier review had missed it. My agents corrected the shared text field so a form could turn off manual resizing while keeping automatic growth and scrolling for longer text. The default behavior remained available to other uses.

The decision and its reason were saved with the knowledge governing shared inputs. An Issue tracked the implementation and the work required to bring it into Tasks.

The shared component was corrected, checked and published. Tasks then adopted that release and used the sizing option for both creating and editing instructions.

The field starts compact, expands as the instructions grow, and scrolls when the content needs more room. The recorded desktop and responsive phone checks confirmed that the final line stayed reachable, that clearing the text shrank the field, and that the saved instructions remained intact.

That capability now belongs to the shared field. Another product can use it through the same component. It still needs to choose the behavior that fits its form, adopt a compatible release and check the result.

The Textarea page is the public catalog destination for this shared component.

On October 20, an agent opened the live Tasks creation form and added six lines of text without saving a task. The field grew from 62 to 138 pixels high. All six lines were visible without dragging a handle. Clearing the text returned it to 62 pixels, and the unsaved form was closed.

This is the current interface during that check. It shows the resulting behavior, not a reconstruction of the old defect.

Agents implemented, reviewed, released and checked the work. I supplied the direction and caught the field detail described above.

The October 18 Tasks delivery record includes checks of creation and editing, unsaved-work protection, schedule changes, completion of real scheduled runs, navigation, account-menu behavior and recovery. It records desktop and responsive browser views in both light and dark appearances. Responsive phone-sized windows were used; this was not physical-phone testing.

Further review found other defects, and the work was reopened and corrected. Passing the earlier checks had not made the product finished.

On October 20, public HTTP checks confirmed that the design catalog and Textarea page were available, and that an anonymous visit to Tasks reached its sign-in destination. The separate authenticated browser check above repeated the field-growth behavior; it did not repeat the entire October 18 acceptance.

I also asked for selected text to follow the device’s native appearance instead of our branded highlight. My agents updated the shared theme decision and removed the custom selection styling from the shared implementation.

The design catalog, Cortex, Admin, Cloud Console and Workspace each adopted the published change. The delivery records include the shared release and a separate successful deployment for each of those consumers. The catalog recorded a production selection check; the other records combine local interaction or fixture checks with built-style checks and their deployed entry pages. They do not establish a fresh test of every authenticated production screen.

This shows the same correction reaching several products through one shared implementation. The governing decision remains available to later agents, and a new product using that foundation starts with the updated behavior.

Tasks reused a design system that already existed. A human correction then became a shared capability, and the records show that capability being adopted and checked in Tasks.

Saving the decision did not change the interface by itself. Publishing the component did not update every product. The work had to continue through implementation, adoption and checking.

These records do not measure human time saved, total cost or an improvement rate. They preserve a completed change and the rework it required, so the next decision can build on something concrete.