Checking that nested resource routes bind children to the stated parent

Goal

Validate a relationship that coding agents can omit when building nested endpoints: the requested child must belong to the requested parent under the application contract. This is an original fixture design.

Prerequisites

Use a disposable issue tracker with separate synthetic projects and issues. The test account may access one project. Define whether a mismatched parent-child pair is rejected or resolved through a documented canonical route.

Steps

1. Create an allowed parent-child pair and retrieve it normally. Record the issue identifier, parent identifier, and intended visibility, without copying private content from any real workspace.

2. Keep the allowed parent identifier but substitute the identifier of an issue belonging to the other synthetic project. Inspect both the returned object and any authorization decision.

3. Repeat for mutation operations supported by the fixture, such as renaming an issue. Read both issue records through their owners afterward to detect a write hidden behind an error response.

4. Exercise any alias route that omits the parent. Document its independent policy instead of assuming that a safe nested route automatically makes the shorter route safe.

5. Fix the relationship check at the data-access or policy boundary selected by the application. Rerun the valid pair, mismatched pair, and alias cases using the same fixture identities.

Expected result

A useful regression expresses the permitted relationship directly and rejects a mismatched pair without accidentally rejecting every nested request.

Limits and test basis

This procedure deliberately supplies known fixture identifiers. It makes no claim about identifier guessing, discovery, or exploitability against any deployed service. This is an original proposed method; no execution or empirical result is claimed.