Support declarative repository assets and composable package ownership

[Dongbumlee]

Problem

Repository packages can install Agentic Workflow Markdown, direct-child Actions YAML, skills, and agents, but cannot install other repository assets required by a complete automation product, including:

• .github/ISSUE_TEMPLATE/*.yml
• .github/CODEOWNERS or other governed configuration
• deterministic helper scripts
• policy/catalog JSON files outside skill directories
• package-specific provenance and ownership metadata

The current schema and isSupportedManifestIncludePath / isSupportedPackageInstallablePath filters ignore these entries. As a result, gh aw add-wizard can report success while leaving a package operationally incomplete.

Multiple optional packages also need independent ownership. A single unscoped installation record cannot safely update/remove one module without treating another module's files as stale.

Expected capability

Add a declarative, non-executable repository-assets surface plus package-scoped ownership metadata.

Illustrative syntax (maintainers may choose another shape):

assets:
  - source: templates/bug.yml
    destination: .github/ISSUE_TEMPLATE/bug.yml
  - source: scripts/verify-package.mjs
    destination: .github/aw/scripts/verify-package.mjs
  - source: policy/controls.json
    destination: .github/aw/policy/controls.json

No arbitrary post-install command or shell hook is requested.

Security requirements

• All sources are content from the immutable package ref selected by add/add-wizard.
• Destinations use an explicit allowlist or policy-controlled namespace.
• Reject absolute paths, traversal, symlinks, device files, destination collisions, and case-insensitive collisions.
• Apply writes only after full validation; installation should be transactional or safely recoverable.
• Refuse to overwrite locally modified managed files unless --force is explicit.
• Remove only stale files proven to be owned by the same package.
• Record package source, resolved immutable commit, destination paths, and content digests.
• Never expose configured secrets to package content or execute installed scripts during installation.

Agentic implementation plan

1. Manifest schema

   • Add an assets array to pkg/parser/schemas/aw_manifest_schema.json with source and destination fields.
   • Keep includes, skills, and agents behavior unchanged.

2. Resolved package model

   • Extend resolvedRepositoryPackage with validated asset entries.
   • Fetch asset sources relative to root/nested package path and pin them to the resolved package ref.

3. Ownership/provenance

   • Store one package-scoped record per installed package, for example .github/aw/packages/<stable-package-id>.json.
   • Include source spec, resolved commit SHA, installed destinations, SHA-256 digests, and installer/compiler version.
   • Ensure core and optional packages can coexist without either package claiming or deleting the other's files.

4. Install/update/remove behavior

   • Preflight all paths and collisions before writing.
   • Preserve unrelated files.
   • Reject local drift unless --force is supplied.
   • Delete only files previously owned by the same package and unchanged since installation.
   • Ensure add, add-wizard, update, and remove share the same ownership rules.

5. Tests

   • Cover Issue Forms, scripts, JSON policy files, nested packages, multiple simultaneously installed packages, idempotent update, local drift, stale deletion, forged ownership records, traversal, symlinks, and source/destination collisions.
   • Add an end-to-end add-wizard test proving the resulting target repository contains workflows, skills, agents, deterministic Actions, and Issue Forms.

6. Documentation/specification

   • Extend the repository package manifest specification and CLI reference.
   • Document supported destination namespaces, ownership behavior, --force, update/remove semantics, and why executable post-install hooks remain prohibited.

Acceptance criteria

• gh aw add-wizard can install a complete package that includes Issue Forms and deterministic support assets.
• Two optional modules can be installed, updated, and removed independently.
• Every managed file has immutable source provenance and digest evidence.
• Local or cross-package files are never silently overwritten or deleted.