From 36a98158b613aab7d54c71b60237c4214d5d6c17 Mon Sep 17 00:00:00 2001
From: levonk <277861+levonk@users.noreply.github.com>
Date: Wed, 2 Sep 2026 09:58:09 -0700
Subject: [PATCH] docs(agents): clarify work-on-main applies to maintainers,
 not fork contributors

The "work directly on main" convention in AGENTS.md line 29 was set for
internal small-team rapid development. Third-party contributors on forks
cannot push to main upstream and must work on feature branches to open PRs.
Add an explicit clause so agents reading AGENTS.md on a fork don't commit
to main when a PR is the intended delivery path.

Closes #6
---
 AGENTS.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/AGENTS.md b/AGENTS.md
index 97521fe4..09308605 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -26,7 +26,7 @@ This repository owns the desktop product around an unmodified DeepSeek Harness c
 - The upstream submodule keeps its own PNPM workspace. Run upstream commands through the root `upstream:*` scripts, which enter the submodule before invoking its pinned Corepack release.
 - Compatibility mode must run the upstream default client without overrides. Advanced presentation belongs to desktop-owned client plugins and may replace documented slots or services through profile composition.
 - Keep graphical application launch explicit. Builds, typechecks, unit tests, and Loader smokes must remain headless-safe.
-- During the current small-team rapid-development phase, work directly on `main` unless the user explicitly requests a branch or pull request. Do not create routine PRs.
+- During the current small-team rapid-development phase, work directly on `main` unless the user explicitly requests a branch or pull request. Do not create routine PRs. Third-party contributors on forks should always work on a feature branch and open a PR upstream — the "work on main" convention applies to maintainers with push access, not to fork-based contributors.
 - Commit every important coherent change promptly so regressions can be reverted to a precise checkpoint. Prefer several focused commits over rare large snapshots.
 - Record every important product, architecture, workflow, or operational evolution in [`docs/DEVELOPMENT-LOG.md`](docs/DEVELOPMENT-LOG.md). Commit the implementation first, then add its full canonical commit hash and human-readable explanation to the log in a separate documentation checkpoint. Update logged hashes after any history rewrite or squash.
 - Commit before major changes of direction and keep the submodule pin update separate from desktop behavior changes.