docs: harmonize governance and contribution authority

.github/pull_request_template.md

@@ -52,3 +52,16 @@ Follow [CONTRIBUTING.md](https://github.com/WebFirstLanguage/Scriptorium/blob/ma
 [REPOSITORY_HYGIENE.md](https://github.com/WebFirstLanguage/Scriptorium/blob/main/REPOSITORY_HYGIENE.md).
 
 Report undisclosed vulnerabilities privately using [SECURITY.md](https://github.com/WebFirstLanguage/Scriptorium/blob/main/SECURITY.md).
+
+### Governance evidence
+
+- [ ] Feature/fix/docs branch targets `dev`; no direct protected-branch push.
+- [ ] Current SHA, Actions run links and individual required results are recorded.
+- [ ] Red/Green evidence, or justified documentation-only N/A with doc/link checks.
+- [ ] Skipped, missing, pending and failed checks are explicit, never called passes.
+- [ ] Yomi reviewed this revision; material fixes have fresh CI and review.
+- [ ] Triggered bot reviews finished; findings/discussions are fixed or dispositioned.
+- [ ] PR owner has a real monitor/event continuation while checks or reviews are pending.
+- [ ] No secrets/private data; environment injection and production boundaries observed.
+- [ ] No protection bypass; check/review state is rechecked immediately before merge.
+- [ ] Main/release/tag/deploy authority and Brad-reserved decisions follow GOVERNANCE.md.

.github/workflows/governance.yml

@@ -4,7 +4,7 @@ on:
   push:
     branches: [main]
   pull_request:
-    branches: [main]
+    branches: [main, dev]
   workflow_dispatch:
 
 permissions:

.github/workflows/wfl-tests.yml

@@ -4,7 +4,7 @@ on:
   push:
     branches: [main]
   pull_request:
-    branches: [main]
+    branches: [main, dev]
   workflow_dispatch:
 
 permissions:

AI_POLICY.md

@@ -1,5 +1,10 @@
 # Scriptorium AI Policy
 
+Contribution authority, feature → `dev` PRs, exact-commit CI, Yomi review,
+bot feedback, secrets and production boundaries follow
+[GOVERNANCE.md](GOVERNANCE.md#common-contribution-policy--version-10-2026-09-27).
+
+
 ## AI-assisted contributions are welcome
 
 Generative AI, coding agents, and other automation are legitimate tools for
@@ -56,7 +61,8 @@ Agents must follow [CLAUDE.md](CLAUDE.md) and the root policies. A tool's abilit
 to change files, deploy a site, merge a PR, or publish a release does not grant
 authority to do so. Maintainers remain accountable for project decisions and
 must authorize any delegation for merges, releases, access, or infrastructure.
-AI-generated approval does not substitute for required Maintainer approval.
+A bot summary does not substitute for Yomi’s independent review or the
+conditional CEO/Brad decisions required by GOVERNANCE.md.
 
 ## Changes to this policy
 

CLAUDE.md

@@ -1,5 +1,10 @@
 # Scriptorium — shared agent instructions
 
+Contribution authority, feature → `dev` PRs, exact-commit CI, Yomi review,
+bot feedback, secrets and production boundaries follow
+[GOVERNANCE.md](GOVERNANCE.md#common-contribution-policy--version-10-2026-09-27).
+
+
 Scriptorium is a WordPress-style CMS written entirely in **WFL**, rendering
 through the **Scribe** template engine (a git submodule at `lib/scribe`) and
 persisting to SQLite. Start with [`README.md`](README.md), then
@@ -24,7 +29,8 @@ Protect existing databases, uploads, URLs, theme contracts, and extension
 hooks. Behavioral changes need failing-then-passing test evidence and updated
 docs in the same change. Documentation-only changes need relevant validation,
 not artificial application tests. Do not log or commit secrets or real site
-data. Maintainers own merges, releases, access grants, and policy exceptions;
+data. Merge/release authority follows GOVERNANCE.md’s dev delegation and
+conditional CEO gate; access grants and exceptions remain explicitly governed.
 AI assistance does not change that authority or the quality bar.
 
 `AGENTS.md` points here so agent guidance has one canonical home. Keep this
@@ -119,7 +125,8 @@ violate the standard.
 ## Deployed instances
 
 Live Scriptorium sites (news.starnet and others) are Starnet infrastructure.
-Follow the workspace instructions in the `starnet` folder for those: load the
+Agents may inspect authorized config/logs only; production changes require
+the authority recorded in GOVERNANCE.md. For authorized inspection, load the
 `starnet-devops` and `knowledge-mcp-dev` skills, check the knowledge base before
 acting, and record what changed afterward. Use `git-safe-commit` for any git
 write operation.

CONTRIBUTING.md

@@ -1,5 +1,10 @@
 # Contributing to Scriptorium
 
+Contribution authority, feature → `dev` PRs, exact-commit CI, Yomi review,
+bot feedback, secrets and production boundaries follow
+[GOVERNANCE.md](GOVERNANCE.md#common-contribution-policy--version-10-2026-09-27).
+
+
 Scriptorium welcomes fixes, tests, documentation, themes, accessibility work,
 and improvements to the CMS. You can contribute through a fork and pull request
 without a formal project role. AI-assisted contributions are welcome; the author
@@ -46,7 +51,7 @@ pinned Scribe submodule:
 ```sh
 git clone --recurse-submodules https://github.com/YOUR-USERNAME/Scriptorium.git
 cd Scriptorium
-git switch -c fix/describe-the-change
+git switch -c fix/describe-the-change origin/dev
 ```
 
 For an existing clone, use `git submodule update --init --recursive`. Read
@@ -145,7 +150,7 @@ Use [.github/pull_request_template.md](.github/pull_request_template.md) as the
 canonical body format for every PR, including those created through a CLI,
 API, agent, or dependency updater. Copy it explicitly when your tool does not
 load it. Template completion is a review requirement; it does not replace tests
-or Maintainer approval.
+or the review and merge authority gates in GOVERNANCE.md.
 
 Titles use `<type>(<optional scope>): <imperative summary>`, for example
 `fix(auth): reject expired sessions` or `docs: clarify theme fallback`.

GOVERNANCE.md

@@ -12,6 +12,90 @@ authority, contribution roles, and the policies used to review changes.
 | Project contact | info@logbie.com |
 | License | [Apache-2.0](LICENSE) |
 
+## Common contribution policy — version 1.0 (2026-09-27)
+
+This version records Brad's approved Logbie LLC governance and subsequent dev
+merge and CEO delegations of 2026-09-26. It governs contribution authority;
+the repository's technical, compatibility, testing and licensing rules remain
+binding. Report substantive conflicts on the owning issue instead of silently
+relaxing a rule.
+
+### Branches and review
+
+- Start a short-lived feature, fix or documentation branch from current `dev`;
+  open its PR into `dev`. Never push directly to `dev`, `main` or a release
+  branch, or force-push shared branches. Promotion is `dev → main` by PR.
+- Yomi reviews the current revision against governance and testing policy.
+  The PR author, including an agent author, may merge their own PR into `dev`
+  only after applicable CI passes on that reviewed revision and findings are
+  addressed. This delegation needs no separate per-PR Brad approval.
+- Let triggered bot reviews finish; inspect reviews, inline comments and
+  discussions. Fix actionable findings or record a reasoned disposition and
+  resolve required discussions. Recheck checks and reviews immediately before
+  merging. Material changes require fresh applicable CI and Yomi review.
+- The PR owner remains responsible while CI or bot review is pending. Use an
+  actual scheduled monitor or event-driven continuation, not a promise to watch.
+- Do not bypass protections, use an administrator override, remove a check, or
+  rerun a genuine failure merely to manufacture green. Access is not authority.
+
+### Evidence and testing
+
+- Behavior changes start with a test failing for the intended reason, followed
+  by implementation and passing evidence. Retain exact commands, revisions,
+  results and run links under the repository testing policy.
+- GitHub Actions on the current reviewed revision is merge evidence; local
+  checks supplement it. Enumerate required jobs and their individual results.
+  Missing tools, environment failures, missing/pending checks and skipped,
+  cancelled or failed required suites are blocked verification, never passes.
+  An aggregate green result cannot stand in for an unrun required suite.
+- For prose-only work, record “Behavior tests N/A — documentation only” with
+  the reason and relevant documentation, link and policy checks. This does not
+  waive required CI. Existing risk classes and stricter technical gates remain.
+- Run agent-operated runtime tests on Starnet test VM 136 or 104, never VM 143;
+  coordinate risky-test snapshots with Nodoka. Preserve the repository's approved
+  GitHub Actions execution environments and record their actual results.
+
+### Promotion, release and production authority
+
+Azusa, CEO of Logbie LLC, may approve and perform builds, releases, merges to
+`main`, release promotions, tags and production deployments only when every
+required check passed on the exact commit being acted on: none skipped,
+missing, pending, flaky or failing. Record the SHA, required-check set and
+individual result links, then recheck immediately before acting. A different
+SHA or aggregate green is insufficient; a flaky rerun is not a waiver.
+Anything short of fully green stops for Brad's explicit authorization.
+Yomi's current-revision review and handled bot feedback remain required.
+
+Always Brad's decisions regardless of CI: spending money; deleting data,
+agents or repositories; anything touching secrets; VM configuration changes;
+and removing or weakening required checks. Release/deploy workflow changes,
+organization settings/membership and deletion of branches, rulesets or
+workflows also require Brad's explicit approval through the owning issue.
+
+Production hosts are read-only for agents: authorized config/log inspection
+only, without exposing secrets. No edits, restarts, installs or migrations.
+The conditional CEO production-deployment authority above is limited to the
+authorized deployment; it grants no general production administration.
+Other production changes go to Brad through Azusa.
+
+### Credentials, exceptions and enforcement
+
+Never commit, print, log or paste credentials into files, comments, PRs,
+command arguments or remote URLs. Inject authorized tokens through environment
+variables from approved storage, with minimal scope. Suspected exposure:
+stop propagation, report safe metadata, and coordinate response with Brad.
+Do not borrow another agent's or a human's credentials.
+
+Tie governed changes to an owning issue. Record exceptions with scope, reason,
+risk, owner, expiry and follow-up, and obtain Brad's explicit approval before
+acting. A deviation note is not approval and cannot silently amend policy.
+
+Policy text does not configure GitHub. Verify effective protections and actual
+required checks via the API. Report missing controls, identities and platform
+limits explicitly; never call a convention machine-enforced. In particular,
+a shared author identity cannot supply independent GitHub approval. Deferred
+identity enforcement does not authorize bypass or replace Yomi's review.
+
 ## 1. Policy map
 
 These root documents are binding project policy:
@@ -43,7 +127,8 @@ Anyone may propose changes in any area. Formal Contributor status is optional
 and does not determine the value of a person's work. Elevated repository access
 does not by itself authorize merging to `main`, publishing releases, managing
 credentials, or changing repository settings; those actions belong to
-Maintainers unless explicitly delegated.
+the specific dev/CEO/Brad delegations in the common policy above; repository
+settings still require explicit assigned scope.
 
 Brad is the current primary Maintainer and has the final decision when a
 technical or governance disagreement remains unresolved. Additional Maintainers
@@ -155,7 +240,8 @@ responsibility, security needs, or policy violations.
 
 ## 6. Releases, assets, and licensing
 
-Maintainers control official releases and project publishing credentials.
+Official releases follow the common policy’s conditional CEO/Brad gate.
+Publishing credentials and any secret changes remain Brad’s decisions.
 Release notes must identify the source revision, relevant dependency changes,
 upgrade instructions, and known limitations. The security support scope lives
 in [SECURITY.md](SECURITY.md); no release cadence or backport period is implied.

README.md

@@ -334,3 +334,9 @@ layout remains grandfathered under [docs/PROJECT-LAYOUT.md](docs/PROJECT-LAYOUT.
 ## License
 
 Apache-2.0. See [LICENSE](LICENSE).
+
+## Contribution policy
+
+Read [GOVERNANCE.md](GOVERNANCE.md) and [CONTRIBUTING.md](CONTRIBUTING.md).
+Work on feature branches and open PRs into `dev`; current-revision CI and
+Yomi review are required.

SECURITY.md

@@ -1,5 +1,10 @@
 # Scriptorium Security Policy
 
+Contribution authority, feature → `dev` PRs, exact-commit CI, Yomi review,
+bot feedback, secrets and production boundaries follow
+[GOVERNANCE.md](GOVERNANCE.md#common-contribution-policy--version-10-2026-09-27).
+
+
 ## Development and support scope
 
 Scriptorium is an MVP under active development. Security fixes target the

testing.md

@@ -1,5 +1,10 @@
 # Scriptorium testing policy and project profile
 
+Contribution authority, feature → `dev` PRs, exact-commit CI, Yomi review,
+bot feedback, secrets and production boundaries follow
+[GOVERNANCE.md](GOVERNANCE.md#common-contribution-policy--version-10-2026-09-27).
+
+
 This is Scriptorium's binding testing policy, adapted from WFL's testing
 governance to this WFL application. It defines both required evidence and the
 limits of the tooling that exists today. It does not claim that the repository
@@ -57,7 +62,8 @@ Use the highest applicable class and have the reviewer check the assessment.
 
 Independence means the reviewer did not author the implementation and inspects
 the actual diff and evidence. An independent review agent can provide technical
-review, but project acceptance and merge authority remain with the Maintainer.
+review; project acceptance and merge authority follow GOVERNANCE.md’s
+dev delegation and conditional CEO gate.
 Missing automation does not exempt new or changed behavior from these rules.
 
 ## Runtime and environment
@@ -256,8 +262,8 @@ keyboard behavior, or data integrity.
 checks on Blacksmith Linux and GitHub-hosted Windows.
 [WFL tests](.github/workflows/wfl-tests.yml) runs the complete WFL suite via
 `wfl --execution-timeout 1200 scripts/run_tests.wfl` on
-`blacksmith-2vcpu-ubuntu-2404`. Both workflows run for pushes and pull requests to
-`main` and support manual dispatch.
+`blacksmith-2vcpu-ubuntu-2404`. Both workflows run for pushes to `main`, pull requests to `main` and `dev`,
+and manual dispatch.
 
 WFL tests pulls `bsbyrdwfl/wfl:nightly` from Docker Hub for every run, resolves
 the image digest, and uses that immutable image for that run's runtime checks.
@@ -296,7 +302,7 @@ do not activate host settings. Bot PRs follow the same review and test rules;
 approve pending workflow runs or manually dispatch both Governance and WFL tests
 on the proposed branch and verify that their revisions match the proposal.
 
-Before a production release, the Maintainer MUST identify the immutable
+Before a production release, the authorized actor under GOVERNANCE.md MUST identify the immutable
 Scriptorium and Scribe revisions, runtime version, deployed configuration, and
 candidate artifact if packaged. Run the application suites and real critical
 journeys for that candidate, including installation, upgrade, data recovery,
@@ -332,7 +338,7 @@ compliance. Update this register when tooling or host settings are verified.
 
 ## Exceptions and completion
 
-The Maintainer may approve a narrow temporary exception for unavailable
+Brad may approve a narrow temporary exception for unavailable
 evidence or an emergency mitigation. Record the exact rule, revision, reason,
 approver, compensating checks, recovery plan, expiry, and an owned repair issue
 with a deadline. An author cannot be the only reviewer of their exception.

tests/tooling/ci_targets.test.wfl

@@ -0,0 +1,20 @@
+// Keep dev PR coverage while preserving the main-only push boundary.
+include from "../../scripts/test_support.wfl"
+
+store repo_root as path_dirname of (path_dirname of script_directory)
+
+describe "Governance rollout CI targets":
+    test "both workflows admit dev PRs without broadening push events":
+        for each workflow_name in ["governance.yml", "wfl-tests.yml"]:
+            store workflow_path as path_join of repo_root and ".github/workflows" and workflow_name
+            store raw_workflow as test_read_text of workflow_path
+            // Windows checkout uses CRLF; event semantics do not depend on EOL.
+            store workflow_text as ""
+            for each text_fragment in (split raw_workflow by "\r"):
+                change workflow_text to workflow_text with text_fragment
+            end for
+            expect workflow_text to contain "  pull_request:\n    branches: [main, dev]"
+            expect workflow_text to contain "  push:\n    branches: [main]\n"
+        end for
+    end test
+end describe