Solution settings

Issue tracker

Issue tracker shows the Jira or Azure DevOps solution this solution syncs with. The connection belongs to the tenant (Tenant settings); the solution's Integrations people can Sync now, pause the sync for this solution, and settle its conflicts — a field changed on both sides since the last sync — by keeping CorPole's value or taking the tracker's.

Solution settings for agents

Record language: agents write this solution's records, criteria, questions and work items in it, whatever language you talk to them in. When it is not set, the agent asks during the kickoff.

Go ahead without the kickoff: in a new solution without any Authority record, someone who can make records Authority may let work start before the kickoff interview, with a reason. Agents stop offering the interview and the code gate stops asking until the first Authority record; the choice is kept in the history and can be withdrawn. If the tenant's gate for new solutions is enforced, it still applies.

Authority handover

Solutions created with existing code start in Shadow; everything else is Full. A component can have its own tier (an old repository in Shadow, a new one in Full); the solution's tier is the lowest of its components. Only people who manage the solution's integrations declare the tier; every change is kept in the history. Re-apply the repository kit afterwards so CLAUDE.md says the same.

Inventory lists what governs the solution outside CorPole — agent rule files, requirement documents, ADRs, glossaries, tickets — with its size and status: To move, Moved, Historical or Stays outside. Agents record it during the handover; you settle what stays outside.

Readiness shows the share of settled sources, Authority records, drafts waiting for review and open questions, and whether the next tier is due: Shared needs an inventory, half of it settled and at least one Authority record; Full needs every source settled, no draft waiting and no open question.

Agent policy

Per action — migrations, dependencies, CI/CD, security code, tests, public contracts, merging — choose Allowed, Ask first or Forbidden. The solution inherits the tenant's policy and can only make it stricter. Forbidden CorPole actions are refused by the server; code actions become Claude Code permission rules through the repository kit.

Guarded areas: for security code, tests, public contracts, CI/CD and production access you can list the files that belong to them (e.g. src/auth/**). An agent may change those files only at that action's level: Claude Code asks or refuses before the edit, even without re-applying the repository kit, and the PR check flags them for any client. Areas add up from account to tenant to solution.

When you allow an agent to change a guarded area or ungoverned code in Claude Code, the plugin tells CorPole and the approval is kept in the history: who allowed which agent to do what. Ungoverned code is recorded as your approval only where the edit gate asked you about that file shortly before; a file outside the repository is never recorded as one. When the edit gate asks you, your agent is told too: that the gate asked, why, and that your yes allows that one change and nothing more.

Such an entry reads Allowed in the client, on the Changes page, in the audit trail and in what an agent gets from get_changes: "Not a change of the agent policy: a person allowed, in their client, an edit the edit gate had asked about (file notes.md)." It is not a change of the policy on this page. A file outside the repository is named by its file name only; the full path is in the call itself, under Agent activity, where the call is listed as allowed in the client. When a hook credential reported it, the entry says so.

Components

The parts of the solution — the web app, the mobile app, a service. Add, rename or remove them here (a component with a repository or onboarded modules cannot be removed; the work and records of a removed one move to the main component). Each component has its repositories or monorepo folders, its modules and its technical design, and can be at its own authority tier.

Repositories and CI

Connect each repository of the solution: the provider (GitHub or GitLab), its path (owner/name on GitHub, group/project on GitLab), and for a monorepo the folder and the component it holds. Each repository gets its own webhook secret; add the webhook with the URL shown. On GitLab use it as the secret token, or paste the signing token GitLab generates (stronger). Change requests (pull requests, merge requests) and commits that mention a story, task or defect code link themselves and move the work. CI can report test results with a service token from Agents → Agent tokens. A repository can start a new component (e.g. Mobile app); with several components each can have its own authority tier, and the solution's tier is the lowest. The repository kit writes a GitLab merge request template and a CI file with the merge request check and test results for GitLab repositories.

Pull-request check: authority rules. The CorPole check stops a pull request that builds on something unsettled. An open question about a cited record, or an open conflict between records, fails it. A criterion without a passing test, or a record that is still Draft or Approved, gives a warning. For each rule you choose error, warning or off, or keep the tenant's setting. Every finding tells the agent what to do. To pass one pull request with an open question the team accepts, add the label open-question-accepted.

Check mode and connection health. A newly connected repository's CorPole check starts advisory: it reports what would fail and still passes, so an older repository is not blocked on day one. Once 90% of its checked pull requests cite a record or work item (at least 10 in 30 days), it becomes enforced by itself and the people who manage integrations are told. You can switch it earlier, or keep it advisory. Make the check "CorPole requirements / pr-check" required in the repository's branch protection, then confirm it here. The connection's health lists the webhook, the PR check, the required check, the repository kit, the agent files and recent pull requests, and says what to do about each missing piece.

The AI semantic review and your directions. When the AI semantic review is on, it reads, beside the Authority records the pull request cites, the directions in force in the solution — at most ten, the portfolio ones first, each quoted on one line. It runs when the pull request cites an Authority record or names a direction in force by its code in its title. A diff that plainly goes against a direction gets possible requirement gap with the direction's code, as a warning: it never blocks the merge. A direction whose sentence looks like it holds a secret is not sent.