Skip to content

feat(agent-dev): PM standard — shared projects: project-init --canon, steward reads the charter wherever the epic points, §15 Visibility (ent#588) - #20

Closed
dolho wants to merge 4 commits into
Abilityai:mainfrom
dolho:feat/ent588-shared-projects
Closed

dolho wants to merge 4 commits into
Abilityai:mainfrom
dolho:feat/ent588-shared-projects

Conversation

@dolho

@dolho dolho commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator

Implements Abilityai/trinity-enterprise#588 — operator ruling R21 (2026-09-10): one project-management standard, two visibility levels. A project in canon (agents/<owner>/projects/<slug>/) is managed exactly like one in project_files/<slug>/ — same charter, same registry epic, same steward, same intake, same decision ledger; placement decides only who can read the definition.

Stacked on #19 (ent#585) — the charter envelope + project-envelope rule this lints against. Merge #19 first; this PR then shows only its own commit.

What changes

PROJECT_STANDARD.template.md

  • §1 workspace row: two placements; the path is recorded in the epic and read from there.
  • §4 epic anatomy: the Workspace field's two forms — `project_files/<slug>/` | `canon:agents/<owner>/projects/<slug>/`.
  • §9: the quarantine pass never scans the canon (a canon-placed project is registered by its epic, never discovered from a folder).
  • new §15 Visibility: the R21 table, the charter envelope (the ent#585 contract) and the workspace resolver every project skill uses — first backticked path in the epic's ## Workspace section; canon: → through the x-canon clone (pull --ff-only, never force); other → repo-relative; missing → the epic body is the context; never derived from the slug.

project-init 1.1 → 1.2 — --canon writes project.md + decisions.md into the agent's own canon folder (x-canon enrolment gate, own-folder only, lint, push via /canon-publish) and records canon:agents/<self>/projects/<slug>/ in the epic; adopt --canon <path>; the charter carries the linted envelope at both levels; --dry-run writes the workspace and prints the epic body without touching GitHub.
project-steward 1.2 → 1.3 — resolves the workspace per §15, reads charter + ledger wherever they are, writes nothing into the canon (charter stamps are /canon-reconcile's; a charter/epic status disagreement goes in the digest), quarantine stays on project_files/.
project-intake 1.2 → 1.3, project-task 1.3 → 1.4 — no behaviour change; a passed-through workspace path resolves per §15.
add-project-management 2.0 → 2.1; plugin 1.16.2 → 1.16.3; README.

Verification

  • /project-init Demo Shared --canon --dry-run, headless Claude Code 2.1.274 in a sandbox agent (x-canon: → a local clone of the ent#585-patched canon, agents/testbot/): wrote canon/agents/testbot/projects/demo-shared/{project.md,decisions.md} with the envelope, printed the epic body with ## Workspace = `canon:agents/testbot/projects/demo-shared/`, created nothing on GitHub, ran the linter and reported honestly. canon_lint.py --scope agents/testbot/projects/demo-shared → PASS 0/0 (this surfaced that a dry-run's epic: …#0 failed ent#585's EPIC_RE; fixed on feat(agent-dev): canon projects/ zone — charter envelope, project-envelope lint rule, consume projects mode, reconcile staleness (ent#585) #19 — #0 = not yet registered, reconcile flags it).
  • Steward resolver (verbatim snippet) on ent#497's real body — its Workspace section is prose with `canon/agents/corbin/projects/tandem/` in backticks — resolves to the canon clone and reads Tandem's charter (tldr) + ledger (30 ruling rows) with no local project_files/ copy; the canon: form, a repo-relative form, a pre-§15 body (no field → epic is context) and an invisible path (→ no workspace, noted) each behave as §15 states. A live steward run was deliberately not made against the real registry (it posts comments/labels).
  • Standard renders with every placeholder substituted (grep -c '{{' → 0); audit-wizards gates 1–6 clean on the touched files (the pre-existing CONVENTIONS-word false positive aside); frontmatter version/changelog/banner on all five skills.

Not done here

  • fleet/project-standard.md, the local .claude/skills/project-* re-install and the trinity-skills library refresh (/sync-skill-library → /promote-skill refresh) are trinity-pm's steps after merge.
  • ent#497's Workspace field resolves as-is; rewriting it to the canon: form is optional.
  • add-orchestrator/templates/project-init.md (the orchestrator bundle's own variant reading fleet/project-standard.md) is out of this ticket's scope — flagged for a follow-up so the two project-inits don't drift.

🤖 Generated with Claude Code

dolho and others added 4 commits September 17, 2026 10:36
…elope lint rule, consume projects mode, reconcile staleness (ent#585)

Operator ruling R21 (2026-09-10): one project-management standard at two visibility levels — a
project is managed the same way at agent level (project_files/<slug>/) and at canon level
(agents/<owner>/projects/<slug>/); canon placement decides only who can read it, and company
projects are shared by design and live in canon. The canon plugins knew nothing of the zone.

add-canon 1.6 → 1.7
- templates/conventions.md.template: projects/ in the folder schema + § Projects — the linted
  project.md charter envelope (owner = folder · status in the registry epic's vocabulary
  active|blocked|needs-decision|paused|pending-verification|done · epic owner/repo#N · updated ·
  review_by · tldr) and the append-only decisions.md ledger (owner/status/updated/tldr, no
  review_by, never re-stamped); everything else in a slug folder is unlinted workspace.
- templates/canon-consume.md 1.3 → 1.4: projects mode — `<agent> projects` lists charters,
  `<agent> projects <slug>` serves charter + ledger at a cited canon@<sha>; staleness per
  review_by (paused/done never stale); the epic is named as the authoritative record.
- templates/canon-reconcile.md 1.3 → 1.4: project.md is a doc for staleness — verified against its
  epic via gh (state + status:* label): agree → re-stamp; moved → changed (mirror); unreachable →
  NEEDS-REVIEW. decisions.md is never re-stamped; a ledger envelope failure is flagged, not repaired.

add-canon-lint 1.0 → 1.1
- templates/canon_lint.py: tenth rule `project-envelope` (charter present + keys + epic shape +
  dates + status enum + owner = folder; ledger keys); charter joins staleness with paused/done
  exempt; `projects` joins ALLOWED_TOP, a file directly under projects/ is a layout warn.
- templates/rules.yaml.template + conventions-lint-section.md.template: the new row + § Projects.
- SKILL.md Step 3b: upgrading a live canon — linter and rules.yaml row land in ONE commit (old
  linter exits 2 on an unknown key; new linter defaults a missing row to fail); preserve
  fleet-local linter edits; append the CONVENTIONS subsection by hand (the grep guard seeds the
  section once, never patches it).

agent-dev plugin 1.16.1 → 1.16.2; README rows updated. Verified against a fixture (every arm of
the rule fires; clean charter passes; done/paused exempt; rule `off` honoured; a pre-1.1
rules.yaml still parses) and against the live Abilityai/canon repo (agents/corbin/projects/
goes from a layout WARN to zero findings once its charter exists; sibling canon PR).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ions.md ledger by their own envelopes (ent#585)

The publish path stamps profile.md/docs/*.md with the doc envelope; a shared-project charter
needs its own rule (status in the epic vocabulary, review_by forward on change) and the ledger
must never gain a review_by or lose an entry. Third runtime template the ticket names.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…d — so a scaffold lints before its epic exists (ent#585)

A /project-init --dry-run (ent#588) writes the charter before any GitHub write; the rule
checked shape with #[1-9], so every dry-run scaffold failed project-envelope. Shape stays
strict otherwise; /canon-reconcile flags an unregistered epic as a NEEDS-REVIEW row.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… steward reads the charter wherever the epic points, §15 Visibility (ent#588)

Operator ruling R21 (2026-09-10): one project-management standard at two visibility levels.
A project in canon (agents/<owner>/projects/<slug>/) is managed exactly like one in
project_files/<slug>/ — same charter, same registry epic, same steward, same intake, same
decision ledger; placement decides only who can read the definition. The PM skills knew only
project_files/ and derived it from the slug.

PROJECT_STANDARD.template.md
- §1 workspace row: two placements; the path is recorded in the epic and read from there.
- §4 epic anatomy: the Workspace field's two forms (`project_files/<slug>/` |
  `canon:agents/<owner>/projects/<slug>/`).
- §9: the quarantine pass never scans the canon (a canon-placed project is registered by its
  epic, never discovered from a folder).
- new §15 Visibility: the R21 table, the charter envelope (the #585 contract) and the
  workspace resolver every project skill uses (`canon:` through the x-canon clone, pull
  --ff-only; other → repo-relative; missing → the epic body is the context; never the slug).

project-init 1.1 → 1.2: `--canon` writes the charter + ledger into the agent's OWN canon
folder (x-canon gate, own-folder only, lint, push via /canon-publish) and records the canon
path in the epic; `adopt --canon <path>`; project.md carries the linted envelope at BOTH
levels; `--dry-run` writes the workspace and prints the epic body without touching GitHub.
project-steward 1.2 → 1.3: resolves the workspace from the epic body per §15, reads charter +
ledger wherever they are, writes nothing into the canon, quarantine stays on project_files/.
project-intake 1.2 → 1.3, project-task 1.3 → 1.4: no behaviour change; a passed-through
workspace path resolves per §15, never from the slug.
add-project-management 2.0 → 2.1; plugin 1.16.2 → 1.16.3; README.

Stacked on ent#585 (the charter envelope + the project-envelope rule it lints against).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@dolho

dolho commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator Author

Tested from Trinity (Workspace chat, agent in a real container)

Local Trinity stack, agent sidekick (Claude Code in the agent container): the PR templates installed as ~/.claude/skills/canon-* + project-init, x-canon: pointing at a clone of the ent#585-patched canon (bare repo inside the container — nothing leaves the box), PROJECT_STANDARD.md rendered from the 1.2 template with a registry that has issues disabled (so a real init cannot create anything by accident). Typed into the Workspace by the operator:

/canon-consume corbin projects tandem → charter table (status needs-decision, registry epic Abilityai/corbin-internal#179, product epic ent#497, managing agent corbin/R20, visibility R21), ledger summarised by batch A → B10 (R1–R30), workspace files listed-not-served, footer source: canon@04940ca · 2 files from agents/corbin/projects/tandem/.

/project-init Demo Shared --canon --dry-run … → Linter: PASS — 0 failures, 0 warnings, printed epic body with ## Workspace = `canon:agents/sidekick/projects/demo-shared/`, Epic (dry run — not created) · would be dolho/abilities#0, both success criteria satisfied, and it named the registry blocker (issues disabled) rather than pretending.

/canon-doctor → 9 checks PASS/WARN/INFO + the lint gate FAIL — agents/sidekick/projects/stale-demo/project.md [staleness] … the next /canon-publish will refuse to push until this is resolved → first fix: /canon-reconcile. (The stale charter is the deliberate reconcile fixture.)

/canon-reconcile as a Trinity schedule (canon-reconcile (demo ent#585), triggered by hand, execution success, ~90 s): without a GitHub token in the container → flagged unverifiable: 1, NEEDS-REVIEW row epic … unreachable, stamps untouched; with GH_TOKEN injected via the credentials API → projects: 1 charter · 0 verified · 1 re-mirrored from epic, charter active → needs-decision (#179's live label), review_by +30 d, decisions.md byte-identical, commit under agents/sidekick/ only.

Screenshots of the Workspace thread are on file (ent585-screenshots/), attached separately if a reviewer wants the visual.

@dolho

dolho commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator Author

Superseded by #22 — same commits, now on an org branch (write access granted). Test evidence carried over.

@dolho dolho closed this Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant