# Resource Governance Scaffold Guidance

## Why this note exists

The template guidance now treats OM Resources descriptors as the source of truth for resource identity and governance metadata. Operations code should import descriptors from `core/config/organization-model.ts`, derive runtime `resourceId` / `type` from them, and use `DeploymentSpec` only as the deployment assembly artifact.

This also removes stale references to legacy `resourceMappings`, `organization-model.examples.ts`, `foundations/`, and `operations/resources/**` paths in the template agent guidance.

## Applies to

Template-derived projects that author workflows, agents, integrations, or project-local agent guidance from the SDK scaffold reference.

## Required actions

- When adding a workflow, agent, or integration, author the descriptor first in `core/config/organization-model.ts` under the id-keyed `resources` map.
- Update operations code to derive deployed runtime IDs from descriptors rather than duplicating raw string IDs.
- Treat existing `resourceMappings` mentions in project-local notes as stale migration history.
- Keep runtime invocation calls honest: `/execute`, scheduler targets, and nested execution still call deployed resource IDs.

## Verification

Run these after reconciling local project guidance or resource authoring:

```bash
pnpm -C core test
pnpm -C operations check
pnpm -C operations check-types
```

For UI surfaces that execute resources, also run:

```bash
pnpm -C ui check-types
```

## Not handled by /git-sync

`/git-sync` pulls the updated guidance and template-owned files, but it does not rewrite project-owned workflow definitions or decide System ownership for real tenant resources. Maintainers must review existing project resources and migrate any duplicated raw IDs to descriptor-backed authoring intentionally.
