interdependent-work-graph

Files (5)

• PORTFOLIO_PLAN.md
• SKILL.md
• portfolio-plan.schema.json
• portfolio_plan.py
• repository-plan-report.schema.json

SKILL.md (first lines)

# interdependent-work-graph — coordinate the problem, not the folder

Repository boundaries preserve authority, provenance, permissions, and release history.

## Core contract

```text
repository boundary != agent boundary
repository boundary == authority and provenance boundary
```

- Resolve the complete participating graph before choosing where to edit.
- Record exact commits, not only branch names or package availability.
- State what authority each repository or evidence source owns.
- Let one agent coordinate the graph, or let several agents consume the same deterministic graph record.
- Transfer no semantic authority, theorem status, certification status, measurement validity, or empirical status merely because repositories are connected.
- Preserve unresolved mappings and authentication questions as `hmmm`.

## Non-trigger

Do not load this skill merely because a repository has ordinary runtime dependencies. A self-contained patch whose correctness, authority, and validation all remain inside one repository does not require a shared work graph.

Load it when crossing a boundary changes what must be known, preserved, validated, published, or refused.

## Authority model

A participant declares an authority role and a work relation. Common examples:

```text
METAPAT    semantic authority
UCNS       mathematical representation and its own proof/status evidence
EDCM       measurement, projection, and result contracts
skill-lib  reusable build and evidence discipline
corpus     bounded external source evidence
website    publication and presentation consumer
```

These are examples, not a universal fixed list. Read the participating repositories before assigning roles.

## Workflow

1. **Discover the graph.** Identify every repository, package, corpus, schema, workflow, or publication surface whose exact state can change the answer.
2. **Resolve identity.** Pin an exact commit, immutable artifact digest, versioned schema, or explicit `hmmm` for each participant. Moving branch names are navigation aids, not evidence identities.
3. **Assign authority.** State what each participant may define and what it merely consumes.
4. **Declare relations.** Record producer, consumer, evidence source, build-doctrine source, publication target, compatibility peer, or other precise relation.
5. **Declare non-transfer boundaries.** At minimum consider authority, proof status, certification, measurement validity, empirical validity, and user-data permissions.
6. **Choose edit locations.** Patch each claim at its owning source. Do not repair a producer defect by shadowing its schema in a consumer.
7. **Coordinate execution.** Prefer one shared identity record, fixture, or manifest that all agents and workflows consume over separate repo-local reconstructions.
8. **Validate the graph.** Run repository-local gates plus at least one cross-repository fixture or identity check proving that the connected surfaces remain distinct and compatible.
9. **Publish bounded results.** Each PR describes its local changes and cites the shared graph identity. Do not merge dependent consumers before required producers are available.
10. **Carry hmmm forward.** Unknown semantic mappings, signatures, release ordering, or governance choices remain explicit boundary objects.

## Stack-manifest reference contract

The first executable reference shape is:

```json
{
  "schema": "the-interdependency.stack-manifest",
  "version": "1.0.0",
  "work_graph_sha256": "<sha256>",
  "repositories": [
    {
      "repository": "owner/name",
      "commit": "<40-hex commit>",
      "authority": "what this participant may define",
      "relation": "how it participates in this work"
    }
  ],
  "boundaries": {
    "authority_transfer": false,
    "proof_status_transfer": false,
    "measurement_status_transfer": false,
    "semantic_mapping": "external-provenance|declared mapping|hmmm",
    "agent_scope": "cross-repository-work-graph",
    "hmmm": [
      "No unresolved boundary in this graph; further uncertainty belongs to a later revision."
    ]
  }
}
```

The digest is SHA-256 over canonical JSON containing exactly `repositories` and `boundaries`, sorted by key with compact separators. In version 1.0.0 the order of the `repositories` array is itself part of the hashed identity: an emitter lists participants in a declared, stable order, and the same participants in a different order produce a different digest. Key sorting does not reorder arrays, so two agents rebuilding the same graph must consume the emitter's declared order rather than re-discovering it. Consuming implementations may add versioned fields only through an explicit schema revision.

Version 1.0.0 also requires `boundaries.hmmm` to remain a visible boundary object: it is a non-empty list of non-empty strings. Record each material unresolved constraint there. When no material unresolved constraint remains, do not collapse the field to `[]`; carry a brief explicit closure note so later readers can distinguish "considered and currently empty" from "boundary silently omitted." The closure note does not invent uncertainty and may be replaced when a real unresolved constraint appears.

The 1.0.0 `boundaries` block is the minimal machine-carried set. Certification-status and empirical-validity non-transfer are binding obligations of this skill (workflow step 5) even where a 1.0.0 manifest carries no explicit fields for them; explicit `certification_status_transfer` and `empirical_status_transfer` fields arrive through the next schema revision, not through ad-hoc emitter extensions. Non-repository participants (corpus, package, schema, workflow, or publication surfaces) are encoded in 1.0.0 as `repositories` entries whose `authority` and `relation` describe the evidence source; typed participant records are likewise deferred to a schema revision.

A manifest is identity and coordination evidence. It is not cryptographic producer authentication unless a separate signature contract exists.

## Workflow separation

For expensive or generated cross-repository work:

- Pull requests validate read-only whenever possible.
- Materialization is an explicit operation with narrow write permission and a named non-default target branch.
- Generated evidence is sealed once and reused by later agents or workflows rather than independently reconstructed.
- A write-back workflow must not patch source code immediately before claiming to validate that source.
- Repository-specific artifacts include the shared graph identity when their interpretation depends on the graph.

## Output shape

When this skill is active, produce or maintain:

```markdown
## Work graph
- participant: exact identity — authority — relation

## Edit ownership
- repository/path: change and why it belongs there

## Cross-repository boundaries
- no-transfer statements
- permission boundaries
- hmmm

## Validation
- local gates
- shared fixture or manifest check

From The-Interdependency/skill-lib, MPL-2.0.

More from The-Interdependency/skill-lib