# Review subproject scope under its actual parent

Illustrative planning brief; no automatic product import.

Illustrative case: two subprojects are named “CLI,” but only one belongs to the project requested by the operator.

## Decision

Use the verified parent and stable subproject reference; do not assume a rename also moves the parent.

## Owned work

- Resolve the parent
  - Owner role: Coordinator
  - Acceptance evidence: The requested project is identified from scoped discovery.
- Read matching subprojects
  - Owner role: CLI user
  - Acceptance evidence: Results are compared with their actual parent references.
- Respect the edit boundary
  - Owner role: Editor
  - Acceptance evidence: The proposal uses supported fields and does not invent parent reassignment.

## Workflow

1. Confirm which parent project the requester means before searching for the child named CLI.
2. Compare each child’s stable reference and parent relationship, then record the one that matches the requested scope.
3. Review only supported editable fields; explain that the inspected update interface does not establish a parent-move operation.

## Judgment

The packaged command map documents no parent reassignment through subprojects update.


## Filled illustrative planning example

Synthetic inventory: CLI-A belongs to Platform API; CLI-B belongs to Tooling. The request concerns Tooling, so only CLI-B is eligible. Renaming CLI-A would not make it a child of Tooling.


## Scope conditions

- Workspace / Requested membership is accessible / Stop if the workspace is inaccessible
- Parent project / Verified project ID matches the request / Resolve ambiguity before filtering
- Subproject edit / Installed help supports the proposed field / Do not invent a relationship-write field


## Workflow questions

### Is the title a unique identifier?

No. Confirm the stable ID and parent context.

### Can I move it using the update command?

Do not assume that. The inspected package documents parent reassignment as unavailable.

## Product connection

This manual brief helps an authorized TeamBoost CLI user keep identity, query scope and review evidence explicit. Check the installed interface and account access before using a source-backed command.

Confirm account availability before adopting this manual outline.


## Keep identity and editable scope separate

The saved interface evidence supports reading the parent relationship, not assuming every relationship can be changed.

### Confirmed child reference

Keep separate: A different child with the same name.

Why the boundary matters: Parent context determines which CLI subproject belongs to the request.

### Supported rename proposal

Keep separate: Parent reassignment through an undocumented update.

Why the boundary matters: Changing a label does not establish a move between projects.