Promote Develop to Main

.agents/skills/agent-conduct/SKILL.md

@@ -35,7 +35,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, propose the fix upstream** rather than only patching it locally, since a local fix leaves every sibling repo with the same trap.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.agents/skills/resync-a-repo/SKILL.md

@@ -42,6 +42,10 @@ stale clone answers confidently instead of failing, and verify the host with
 RESYNC.md section 2, against the target's `main` branch, never `develop`. A finding is a snapshot,
 so quote the run stamp in anything derived from it and re-run before acting on a finding read
 earlier in the session.
+File any hub defect this work exposes against `ptr727/ProjectTemplate`.
+Examples include bugs, conflicting sources, unclear or incomplete instructions, missing capabilities, and Copilot findings about any of them.
+Search open and closed issues first, then update the matching issue or file a new one.
+Preserve the evidence RESYNC.md section 2 requires, and do not leave the finding only in chat, a review thread, the downstream repo, or agent memory.
 
 ## Apply, in this order
 

.claude-plugin/fleet-skills/.source-digest

@@ -1 +1 @@
-d8de3601d734f326
+598e48f2c76dc42b

.claude-plugin/fleet-skills/skills/agent-conduct/SKILL.md

@@ -35,7 +35,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, propose the fix upstream** rather than only patching it locally, since a local fix leaves every sibling repo with the same trap.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.claude-plugin/fleet-skills/skills/resync-a-repo/SKILL.md

@@ -42,6 +42,10 @@ stale clone answers confidently instead of failing, and verify the host with
 RESYNC.md section 2, against the target's `main` branch, never `develop`. A finding is a snapshot,
 so quote the run stamp in anything derived from it and re-run before acting on a finding read
 earlier in the session.
+File any hub defect this work exposes against `ptr727/ProjectTemplate`.
+Examples include bugs, conflicting sources, unclear or incomplete instructions, missing capabilities, and Copilot findings about any of them.
+Search open and closed issues first, then update the matching issue or file a new one.
+Preserve the evidence RESYNC.md section 2 requires, and do not leave the finding only in chat, a review thread, the downstream repo, or agent memory.
 
 ## Apply, in this order
 

.github/skills/agent-conduct/SKILL.md

@@ -35,7 +35,7 @@ Claims about a pull request being reviewed, clean, or mergeable are owned by the
 ## When a Failure Surfaces a Lesson
 
 - **Durable knowledge lands in the committed docs, not in agent memory**, as part of the change that surfaced it, per `GOVERNANCE.md` "Durable Knowledge and Self-Improvement". Memory does not survive a new session or machine, so it holds only environment nuance and in-flight state.
-- **Where the governing doc is carried from the hub, propose the fix upstream** rather than only patching it locally, since a local fix leaves every sibling repo with the same trap.
+- **Where the governing doc is carried from the hub, file the finding against `ptr727/ProjectTemplate`** rather than only patching it locally. A local fix leaves every sibling repo with the same trap. Search open and closed issues first, then update the matching issue or file a new one.
 - **A review flags an instance, so fix the class**: sweep for the siblings before replying, because reviewers sample rather than enumerate.
 - **A rule that keeps needing restating** is usually a stale or missing skills install, so run `python3 scripts/skills_install.py --report` from a hub checkout (the `fleet-conformance-check` skill) before concluding the rule does not exist.
 

.github/skills/resync-a-repo/SKILL.md

@@ -42,6 +42,10 @@ stale clone answers confidently instead of failing, and verify the host with
 RESYNC.md section 2, against the target's `main` branch, never `develop`. A finding is a snapshot,
 so quote the run stamp in anything derived from it and re-run before acting on a finding read
 earlier in the session.
+File any hub defect this work exposes against `ptr727/ProjectTemplate`.
+Examples include bugs, conflicting sources, unclear or incomplete instructions, missing capabilities, and Copilot findings about any of them.
+Search open and closed issues first, then update the matching issue or file a new one.
+Preserve the evidence RESYNC.md section 2 requires, and do not leave the finding only in chat, a review thread, the downstream repo, or agent memory.
 
 ## Apply, in this order
 

.github/workflows/build-docker-task.yml

@@ -203,7 +203,7 @@ jobs:
           platforms: arm64
 
       - name: Setup Buildx step
-        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
+        uses: docker/setup-buildx-action@37fe631027851001ddb9b187196cc803df7f5f0e # v4.3.0
         with:
           platforms: ${{ env.PLATFORMS }}
 

AUDIT.md

@@ -127,7 +127,7 @@ Write `reports/<repo>/audit.md` from [`reports/_template.md`][template]: a dimen
 
 **The hub authors the report, and a downstream repo does not open a pull request against the hub to write its own.** `reports/` is the hub's evidence that it audited a repo, so a report written by the repo being audited is a claim rather than evidence, and the hub cannot adopt one without checking it. Checking the judgment dimensions **is** the audit, since confirming a verdict like "analyzers enforced" means reading the same files the audit reads, so a submitted report saves only the writing up and not the work. A submitted report is also stale by construction, because it is a snapshot of one hub revision arriving at a later one, and its claims then have to be reconciled against findings that did not exist when it was written.
 
-What a downstream repo does instead is unchanged and is where its context is worth most: it **files findings about the hub as issues**, which is the opposite of self-certification and is how several hub defects have been found, and it **applies fixes to its own repo** per section 10. Any pull request it does open against the hub follows the same branching model as every other, targeting `develop` and never `main`.
+A downstream repo uses its context where it is worth most. It **files findings about the hub as issues against `ptr727/ProjectTemplate`** and **applies fixes to its own repo** per section 10. Filing an issue is the opposite of self-certification, and it is how several hub defects have been found. Hub findings include bugs, conflicting sources, unclear or incomplete instructions, missing capabilities, and Copilot findings about any of them. Search open and closed issues first, then update the matching issue or file a new one. Any pull request it opens against the hub follows the standard branching model. It targets `develop`, never `main`.
 
 **Findings are a point-in-time snapshot. Stamp them and re-verify before acting.** [`spec/audit.py`][audit-runner] prints a run stamp (`audit run <UTC> | hub <sha>`) and, per repo, the exact commit it read (`@ <branch>@<sha>`). Anything derived from a run (a report, and especially an **onboarding or conformance issue**) quotes that stamp, so a reader can tell whether it still applies. A convergence issue is generated from the audit, never composed by hand: `spec/audit.py --issue <repo>` emits a ready-to-file title and body from that repo's live findings (grouped into must-fix, converge, and could-not-verify), so the issue content cannot drift from what the audit actually found and regenerates as the repo changes.
 

RESYNC.md

@@ -65,6 +65,8 @@ python3 spec/fidelity_honesty.py --report       # regenerate reports/divergences
 
 **A finding is a snapshot.** Quote the run stamp (`audit run <UTC> | hub <sha>`) in anything derived from the run, and re-run before acting on a finding written earlier, because a repository moves between filing and pickup and a stale list leads to re-fixing what is already fixed.
 
+**File defects in the hub against `ptr727/ProjectTemplate`.** This includes bugs exposed by the resync or its tooling and conflicts between hub sources. It also includes unclear or incomplete instructions, missing capabilities, and Copilot findings about any of them. Search open and closed issues first. Update an existing issue when it tracks the same problem, or file a new one. Do not leave the finding only in chat, a review thread, the downstream repository, or agent memory. Include the observed evidence, the affected repository and ref, and the expected and actual behavior. Include the audit run stamp when the finding comes from an audit. A target-repository convergence issue remains separate and uses the generated `python3 spec/audit.py --issue` content above.
+
 ## 3. Apply, in This Order
 
 The order is load-bearing. Each step below either changes the rules the later steps are judged against, or removes something a later step would otherwise refresh.