modelo_projetos / Examples

See the model in a delivery.

Examples for you to adapt. They are not finished features or measured results.

From a broad request to a clear check

Initial request: “improve task management”. First define the flow: who creates a task, who may edit it, what is stored and how the user sees the result.

REQ-TASK-01
A signed-in user creates a task with a valid title.
The task belongs to the user’s authorized scope.
The author gets confirmation and can reopen the detail.

Acceptance:
- reject an empty title;
- block access from another scope;
- keep the data after reload.

Split work without losing the flow

  • PKG-01: create and view tasks. The goal is one complete, verifiable flow.
  • Batch 1: creation rules, access and storage, with focused tests.
  • Batch 2: form and detail using the contract; test success and errors.
  • Closure: review consumers, reload, access, documents, checks and rollback.

Record gaps without hiding the state

If the API and UI exist but cross-scope access still fails, the requirement is not verified. Record the partial or conflicting state, evidence, pending work and responsible module.

Requirement: REQ-TASK-01
State: Partial
Evidence: create and reload checked with a controlled fixture
Pending: cross-scope access still needs a fix
Module: tasks / access
Next retest: allowed case + denied case

A starting prompt for an assistant

Use this as a starting point and adapt it to the task. File references do not grant permission to deploy, delete data or change branches.

Read PATHS.toml and PRD.md.
Inspect the architecture and Git state before changes.
Implement REQ-TASK-01 in the task flow.
Read the topic documents needed for this scope.
Keep existing conventions. Separate UI, rules and infrastructure.
Check creation, storage and scope-based access.
Update the evidence and report what was actually tested.
Do not push, deploy or delete data without permission.

When the task is a bug

Reproduce the failure before proposing a cause. Separate a hypothesis from a confirmed diagnosis. Fix the responsible module and retest the same case. Add checks if contracts, data, access or several consumers are affected.

Adoption mistakes to avoid

  • Copying “complete” states from another project.
  • Writing long documents with no link to real code or decisions.
  • Asking AI to invent paths, stacks or commands.
  • Treating deployment, device use and acceptance as automatic results of a build.
  • Removing checks to hide implementation failures.
Keep readingDownloads →