Business recipes
Adapt projects, tasks and comments to client tracking, support requests and internal validation in one Starter Pro codebase.
Choose a workflowLink to section
Build on the same workspace, project, task and discussion foundation. Each guide starts with a workflow you can try in the included app, then identifies the presentation changes and domain extensions to review.
Client tracking
Support requests
Internal validation
One foundation, three guided adaptations
These are documented uses of the existing Projects module. They do not install separate products or add a customer portal, email ticketing or a formal approval engine. The baseline walkthroughs need no additional schema or provider.
Reuse the working modelLink to section
| Foundation | Included behavior | Adaptation boundary |
|---|---|---|
| Projects | Name, description, status, responsible member and archive state | An engagement, queue or review request |
| Tasks | Title, description, status, responsible member and calendar due date | A follow-up, support request or review step |
| Comments | Plain-text task discussion with author and creation time | Internal notes and working context |
| Workspace access | Live membership and scoped server operations | The access boundary remains the workspace |
| Activity | Actor/resource events for work changes | Operational history, not an immutable decision record |
Projects and tasks use TODO, IN_PROGRESS and DONE. Their states are
independent; task completion does not complete a project automatically.
An assignee identifies a responsible workspace membership and does not restrict
who can edit. A due date is a calendar target, not a reminder or SLA timer.
Keep the default access rulesLink to section
OWNER, ADMIN and MEMBER can create/edit project work and post comments. A MEMBER can remove its own comments; OWNER and ADMIN can delete tasks and moderate others' comments. All active workspace members can read the workspace's projects and discussions. Revoked membership loses access.
Use an internal team workspace for the walkthroughs. A project is not a customer-specific access boundary, and assigning a reviewer does not create an approval permission. Archived projects block task/comment writes until restored; archive does not make records immutable.
Find the guides in your sourceLink to section
The buyer ZIP includes docs/recipes/README.md and three detailed guides:
client-tracking.md, support-requests.md and internal-validation.md in that
same directory. They include model mappings, example records, source entry
points, acceptance checks and scoped coding-assistant prompts.
Start with installation, then keep the customization and upgrade baseline. Interface labels support French/English; user-authored names and comments remain user data. Use fictitious information when trying the public demo.
Verify your adaptationLink to section
Confirm persistence after reload, MEMBER edits and moderation restrictions, cross-workspace ID rejection, revoked access and archived-task rejection. Review new UI in French/English, light/dark appearance, keyboard navigation and a narrow viewport. Add tests for any new domain behavior.