What We Are Allowed to Touch¶
Source: hooks/ways/softwaredev/delivery/groundwork/permission/permission.md
Frontmatter
| Field | Value |
|---|---|
description |
when contributions cluster on the files people are allowed to edit because the tests, pipeline, or deployment belong to another team, naming the ownership boundary and the decision it needs instead of building around it |
vocabulary |
permission allowed to change not allowed can't touch ownership boundary another team owns platform team owns the pipeline approval negotiate their backlog authority route around workaround wrapper script periphery clustered on config skew who can change this |
refire |
0.2 |
scope |
agent, subagent |
People work on what they have permission to change. An engineer can edit a skill file without asking anyone. Improving the tests may need another team's approval; fixing the deploy may need two managers to negotiate. So the skill file gets better and the build stays broken.
This shows up in a repository as skew: a queue heavy with docs, config, adapters, prompts, and new abstractions on top, while the layer underneath goes untouched. Skew is diagnostic information about the project.
What we do when we hit the boundary¶
- Name it. Which condition in
delivery/groundworkis missing, who owns the thing that would fix it, and what decision or access is needed. Write that down as a finding. - Do not compensate with a primitive. Another agent, a longer prompt, or a wrapper around the broken step hides the boundary and adds something else to maintain.
- Hand the decision to a person. We cannot negotiate a place in another team's planning cycle. Surface it as a choice (see
choices): who needs to say yes, what existing commitment moves, how soon the return is wanted. - Watch for the standing intervention. If a leader has to step in every time to get a change deployed, that dependency is itself a missing condition. Put it in the report.
Common Rationalizations¶
| Rationalization | Counter |
|---|---|
| "That's the platform team's backlog" | It can sit in their backlog for a very long time. Name who decides the priority. |
| "I can at least improve what I can reach" | Improving the periphery while the core is untestable is the pattern we are trying to stop. Report the boundary first. |
| "A wrapper script gets us past it for now" | It gets us past it silently, and the boundary stays. |
| "They'll get to it" | Maybe. Give the human a decision. |
See Also¶
- choices(meta) — presenting a genuine decision to the human
- trust/autonomy(meta) — when to act and when to check in
- delivery/groundwork(softwaredev) — parent: the conditions the boundary is blocking