Workspace governance - #483
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🧹 Nitpick comments (1)
docs/work-items/workspace-work-item-types.md (1)
209-211: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd language identifiers to the formula code fences.
Add
textor the supported formula language to the three fenced examples. This resolves the MD040 lint warnings.Also applies to: 215-217, 221-223
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/work-items/workspace-work-item-types.md` around lines 209 - 211, Add a language identifier, such as text or the supported formula language, to the code fences around all three formula examples in the workspace work-item documentation, including the examples near estimate_point and the referenced sections. Ensure every fenced block satisfies MD040.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/automations/custom-automations.md`:
- Line 324: Update the “Workspace governance” link in custom-automations.md to
use the relative workspace-administration/workspace-governance target, matching
the existing link convention and omitting the .md suffix.
- Line 34: Update the “Automations under workspace governance” link label in the
documentation to remove the stray backtick from “governance,” leaving the link
target and surrounding text unchanged.
- Around line 24-28: Update the project-automation steps referenced by the plan
comparison table to clarify the plan availability of the “Run Script” action. If
the action is Enterprise-only, add an explicit Enterprise plan qualifier or
guard to that step; otherwise update the Business row in the table to include
it, keeping the documented capabilities consistent.
In `@docs/core-concepts/issues/states.md`:
- Line 15: Update the internal links in the states documentation: change the
governance reference on the line containing “Under Enterprise Grid governance”
to the existing “Under workspace governance” anchor, and replace the empty
intake fragment with the appropriate intake documentation link or remove the
link.
- Around line 84-95: Update the deletion rules in the state documentation to
scope the default-state restriction and “set a different default” instruction to
project-managed settings only. For governed workspaces, describe deletion using
the workflow-reference restriction already stated in the Enterprise Grid
section, including the applicable workflow behavior; apply the same
governance-specific wording to the related section around the additional
referenced lines.
In `@docs/work-items/workspace-work-item-types.md`:
- Around line 64-72: Update the availability rule in this document to explicitly
include Mandatory and the default Task type as implicit project types, while
preserving the rule for imported types. Ensure the wording makes clear that
these types are available without project-level import.
- Around line 125-126: Update the setting label in the “Single or multi select”
section heading to the standard compound form “Single- or multi-select,” leaving
the surrounding description unchanged.
- Line 168: Resolve the conflicting editability rules in the work-item type
documentation: update the statement near the date-format property to explicitly
state whether date format remains changeable after values exist, consistent with
the type-specific settings immutability rule, and ensure the later guidance uses
the same policy.
- Around line 192-223: Update the formula documentation around “Referencing
fields” and all related examples to render field references as {{field_name}}
without literal backslashes, including fenced formula examples. Preserve the
existing escaping only where needed for documentation markup, ensuring readers
can copy valid formulas directly.
In `@docs/workflows-and-approvals/workflows.md`:
- Around line 35-40: Update the introductory capability summary above the plan
table to describe only the shared workflow builder and avoid claiming that all
plans provide the same conditions or features. Keep the Business and Enterprise
Grid distinctions in the existing plan capability table unchanged.
- Around line 66-73: Update the workflow documentation around the
default-workflow and new-workflow descriptions to distinguish project-managed
states from governed states. Explain that non-governed projects configure and
select their own project states, while Enterprise Grid governance uses states
from the shared workspace catalog and project admins cannot configure them.
In `@docs/workspace-administration/workspace-governance.md`:
- Around line 86-89: Update the Required-workflow entry in the workflow
precedence list to replace “the project's required workflow” with “the
workspace-mandated workflow,” preserving the existing ordering and all other
terminology.
- Around line 19-26: Update the governance overview around “Enabling governance
lifts all of the following” to include templates and recurring work items,
matching the configuration types described later in the document around lines 42
and 59; preserve the existing links and descriptions for the other centralized
settings.
---
Nitpick comments:
In `@docs/work-items/workspace-work-item-types.md`:
- Around line 209-211: Add a language identifier, such as text or the supported
formula language, to the code fences around all three formula examples in the
workspace work-item documentation, including the examples near estimate_point
and the referenced sections. Ensure every fenced block satisfies MD040.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 7c74f4da-4ba7-4d38-b7c7-3185e3096341
📒 Files selected for processing (6)
docs/.vitepress/config.tsdocs/automations/custom-automations.mddocs/core-concepts/issues/states.mddocs/work-items/workspace-work-item-types.mddocs/workflows-and-approvals/workflows.mddocs/workspace-administration/workspace-governance.md
| | Plan / setup | Where you configure automations | What you get | | ||
| | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ||
| | **Business** | Inside each project, under **Project Settings → Automations** | Custom automations scoped to one project, with the **Change property** and **Add comment** actions. | | ||
| | **Enterprise Grid** (project-managed) | Project settings, plus **Workspace Settings → Automations** | Everything above, plus **workspace automations** that span all projects or a chosen subset, the **Send webhook** and **Run script** actions, and **scheduled** triggers. | | ||
| | **Enterprise Grid with [Workspace Governance](/workspace-administration/workspace-governance)** | Once for the whole workspace, under **Settings → Automations** | Automations are managed centrally by a workspace admin and applied to projects. Project admins no longer create or edit automations inside a project. | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Align the plan table with the project-automation steps.
The table limits Business project automations to Change property and Add comment. The later project-automation steps list Run Script without a plan guard. Clarify whether Business supports this action. If it is Enterprise-only, mark the later step as plan-specific.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/automations/custom-automations.md` around lines 24 - 28, Update the
project-automation steps referenced by the plan comparison table to clarify the
plan availability of the “Run Script” action. If the action is Enterprise-only,
add an explicit Enterprise plan qualifier or guard to that step; otherwise
update the Business row in the table to include it, keeping the documented
capabilities consistent.
|
|
||
| - On **Business**, automations live in **project settings** and act on that one project. | ||
| - On **Enterprise Grid without governance**, you keep project automations and can also create **workspace automations** and use the webhook and script actions. | ||
| - On **Enterprise Grid with [Workspace Governance](/workspace-administration/workspace-governance)**, automation management moves to the **workspace level**. Project admins can no longer edit automations inside a project. See [Automations under workspace g`overnance](#automations-under-workspace-governance). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Remove the stray backtick from the link label.
Change Automations under workspace g\overnancetoAutomations under workspace governance`.
🧰 Tools
🪛 LanguageTool
[style] ~34-~34: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...d use the webhook and script actions. - On **Enterprise Grid with [Workspace Gover...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 markdownlint-cli2 (0.23.1)
[warning] 34-34: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/automations/custom-automations.md` at line 34, Update the “Automations
under workspace governance” link label in the documentation to remove the stray
backtick from “governance,” leaving the link target and surrounding text
unchanged.
| Each project defines its own states, managed by a **project admin** under **Settings → (project) → States**. This is the default. | ||
|
|
||
| **Enterprise Grid - workspace level** | ||
| With [workspace governance](/workspace-administration/workspace-governance) enabled, states become a single shared set for the whole workspace, managed by a **workspace admin** under **Workspace Settings → States**, then applied to every project. Project admins use the shared set but can't edit it. See [Under Enterprise Grid governance](#under-enterprise-grid-governance). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Repair the invalid internal links.
- Line [15] links to
#under-enterprise-grid-governance, but the section heading isUnder workspace governance. Use#under-workspace-governanceor rename both references. - Line [63] uses
[intake](#), which is an empty fragment. Link to the intake documentation or remove the link.
Also applies to: 63-63
🧰 Tools
🪛 markdownlint-cli2 (0.23.1)
[warning] 15-15: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/core-concepts/issues/states.md` at line 15, Update the internal links in
the states documentation: change the governance reference on the line containing
“Under Enterprise Grid governance” to the existing “Under workspace governance”
anchor, and replace the empty intake fragment with the appropriate intake
documentation link or remove the link.
Source: Linters/SAST tools
| **Delete** - remove a state, subject to these rules: | ||
|
|
||
| - The **default state cannot be deleted**. Set a different default first. | ||
| - A state with **work items cannot be deleted** - there is no automatic reassignment. Move its work items to another state first, then delete it. | ||
| - The **triage state cannot be deleted**. | ||
| - A group's **last remaining state cannot be deleted**. | ||
|
|
||
| Deleting a state is permanent. | ||
|
|
||
| :::info **Enterprise Grid** | ||
| A state also **cannot be deleted while a workflow uses it** - the error names the workflows. Remove the state from those workflows first. Project admins cannot create, edit, or delete states at all; state management happens at the workspace level. | ||
| ::: |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Scope the deletion rules by governance mode.
Line [58] says governed workspaces do not have a state-level default. Lines [86] and [117] still say that the default state cannot be deleted and instruct readers to set another default. Keep that rule under project-managed settings. Describe governed deletion using workflow-reference rules, as stated on Line [94].
Also applies to: 115-123
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/core-concepts/issues/states.md` around lines 84 - 95, Update the
deletion rules in the state documentation to scope the default-state restriction
and “set a different default” instruction to project-managed settings only. For
governed workspaces, describe deletion using the workflow-reference restriction
already stated in the Enterprise Grid section, including the applicable workflow
behavior; apply the same governance-specific wording to the related section
around the additional referenced lines.
| **Referencing fields.** Reference another property with double curly braces: `\{\{field_name\}\}`. Field names are matched case-insensitively and ignore spaces versus underscores, so `\{\{start_date\}\}`, `\{\{Start Date\}\}`, and `\{\{START_DATE\}\}` all resolve to the same field. A formula can reference Text, Number, Date, and Boolean properties on the same work item type, and cannot reference itself. | ||
|
|
||
| **Result types.** A formula evaluates to a Number, Text, Date, or Boolean. | ||
|
|
||
| **Operators.** | ||
|
|
||
| - Arithmetic on numbers: `+ - * /` | ||
| - Dates: `\{\{end\}\} - \{\{start\}\}` gives the number of days; `\{\{date\}\} + 30` and `\{\{date\}\} - 7` shift a date. | ||
| - Text concatenation: `&` (numbers, dates, and booleans are converted to text automatically). | ||
| - Comparisons: `= != < <= > >=` (these return a Boolean). | ||
|
|
||
| **Functions.** `IF(condition, true_value, false_value)`, `ROUND`, `ABS`, `UPPER`, `LOWER`, `LEN`, `CONCAT`, `TODAY()`, `NOW()`. | ||
|
|
||
| **Examples.** | ||
|
|
||
| Categorize by estimate size: | ||
| `{estimate_point} > 5 ? "Large" : "Small"` | ||
|
|
||
| ``` | ||
| IF(\{\{estimate_point\}\} > 5, "Large", "Small") | ||
| ``` | ||
|
|
||
| Flag high-priority items: | ||
| `{priority} == "HIGH" ? "Urgent: " + {name} : {name}` | ||
|
|
||
| Because the value is always derived, formula properties cannot be marked as mandatory. | ||
| ``` | ||
| IF(\{\{priority\}\} = "HIGH", "Urgent: " & \{\{name\}\}, \{\{name\}\}) | ||
| ``` | ||
|
|
||
| Days remaining until a deadline: | ||
|
|
||
| ``` | ||
| IF((\{\{due_date\}\} - TODAY()) < 0, "OVERDUE", (\{\{due_date\}\} - TODAY()) & " days remaining") | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Locate file and relevant docs config/plugins:\n'
fd -a '^(workspace-work-item-types\.md|config\.ts)$' docs || true
printf '\nFile excerpt (lines 180-230):\n'
if [ -f docs/work-items/workspace-work-item-types.md ]; then
sed -n '180,230p' docs/work-items/workspace-work-item-types.md | cat -n
fi
printf '\nRelevant config/plugins references:\n'
rg -n "vitepress-plugin-tabs|plugin|tabs|markdown|raw|formula|\\{\\{|\\\\\\{\\{" docs/.vitepress docs/work-items -S || trueRepository: makeplane/docs
Length of output: 8213
🌐 Web query:
VitePress markdown code spans escaped braces literal backslashes
💡 Result:
In VitePress, the treatment of characters like curly braces and backslashes within code spans and code blocks depends on whether they are being processed by Markdown or the Vue compiler. Inline Code Spans By default, inline code spans (e.g., code ) are processed by the Vue compiler in VitePress. This means that if your inline code contains Vue interpolation syntax like {{ ... }}, VitePress may attempt to evaluate it, leading to build errors [1][2]. To display literal curly braces or other Vue-sensitive characters inside inline code, you cannot rely on standard Markdown backslash escapes, as backslash escapes do not function within standard Markdown code spans (they are treated as literal backslashes) [3][4]. Instead, use the following methods: 1. Use the v-pre directive: Wrap the content in a container or element with the v-pre attribute, which tells Vue to ignore the inner content. For example: {{ 1 + 1 }} [5][2]. 2. Add a Custom Markdown-it Rule: To fix this globally, you can configure your.vitepress/config.js to automatically add the v-pre attribute to all inline code spans during the markdown-it rendering phase [1]: js markdown: { config(md) { const orig = md.renderer.rules.code_inline md.renderer.rules.code_inline = (tokens, idx, options, env, self) => { tokens[idx].attrSet('v-pre', '') return orig(tokens, idx, options, env, self) } } } Fenced Code Blocks Fenced code blocks are automatically wrapped with v-pre by VitePress, meaning they are safe from Vue interpolation by default [5][1]. You do not need to perform additional escaping for braces or backslashes within standard code blocks [5]. Literal Backslashes Because backslash escapes are not supported inside code spans [3][4], any backslash you write inside an inline code span (e.g., \) will be rendered as a literal backslash. If you are experiencing issues with backslash escapes in prose (outside of code spans), ensure you are using a current version of VitePress, as regressions affecting these escapes have been patched in recent updates [6].
Citations:
- 1: website: literal {{ }} in rendered markdown (inline code included) breaks the VitePress build with an opaque Vue error genealogix/glx#1100
- 2: Escaping {{ in markdown in VitePress vuejs/vitepress#480
- 3: https://www.jetbrains.com/help/hub/markdown-syntax.html
- 4: https://gfm.xiniushu.com/Inlines/Code%20spans.html
- 5: https://vitepress.dev/guide/using-vue
- 6: vuejs/vitepress@d02d1e9
Render formula syntax without literal backslashes.
These code spans and fenced examples show \{\{field_name\}\} as a copyable value. Formula properties use {{field_name}}; remove the backslashes so readers do not paste invalid formulas.
🧰 Tools
🪛 markdownlint-cli2 (0.23.1)
[warning] 209-209: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 215-215: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 221-221: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/work-items/workspace-work-item-types.md` around lines 192 - 223, Update
the formula documentation around “Referencing fields” and all related examples
to render field references as {{field_name}} without literal backslashes,
including fenced formula examples. Preserve the existing escaping only where
needed for documentation markup, ensuring readers can copy valid formulas
directly.
| Every plan builds workflows the same way, with the same states, flows, and conditions. What differs is **where** they are configured and **who** manages them. Find your setup below. | ||
|
|
||
| | Plan / setup | Where you configure workflows | What you get | | ||
| | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | **Business** | Inside each project, under **Project Settings → Workflows** | One **default workflow** per project that governs all work items in it. | | ||
| | **Enterprise Grid** (project-managed) | Inside each project, under **Project Settings → Workflows** | Everything above, plus **approval flows**, **transition conditions**, and **multiple custom workflows** scoped to specific work item types. | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the plan capability summary.
Line [35] says every plan uses the same conditions. The table on Line [40] says approval flows and transition conditions are Enterprise Grid-only. Reword the summary to describe only the shared workflow builder. Otherwise Business users may expect unavailable features.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/workflows-and-approvals/workflows.md` around lines 35 - 40, Update the
introductory capability summary above the plan table to describe only the shared
workflow builder and avoid claiming that all plans provide the same conditions
or features. Keep the Business and Enterprise Grid distinctions in the existing
plan capability table unchanged.
| ::: warning **Enterprise Grid with governance** | ||
| There is no per-project **Enable workflows** toggle. Workflows are managed centrally under **Settings → Workflows** at the workspace level, and the workspace always has one default workflow. The list additionally shows how many **projects** and **work item types** use each workflow. | ||
| ::: | ||
|
|
||
| ### Define a workflow | ||
|
|
||
| Whether you're editing the default workflow or a type-specific one, the workflow detail page works the same way. It lists all the states included in the workflow and lets you add flows that control how work items move between them. | ||
|
|
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Separate project states from the governed state catalog.
The paragraph on Line [76] says the default workflow includes states configured in the project and that new workflows select project states. Under governance, states come from the shared workspace catalog, and project admins cannot configure them. State the project-managed and governed behavior separately.
Also applies to: 74-82, 84-96
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/workflows-and-approvals/workflows.md` around lines 66 - 73, Update the
workflow documentation around the default-workflow and new-workflow descriptions
to distinguish project-managed states from governed states. Explain that
non-governed projects configure and select their own project states, while
Enterprise Grid governance uses states from the shared workspace catalog and
project admins cannot configure them.
| Enabling governance lifts all of the following from the project level to the workspace level. Each has its own detailed page: | ||
|
|
||
| - [**States**](/core-concepts/issues/states) - the shared set of states for the whole workspace, including a single workspace triage state. | ||
| - [**Workflows and approvals**](/workflows-and-approvals/workflows) - shared workflows that define how work items move between states. | ||
| - [**Work item types and custom properties**](/work-items/workspace-work-item-types) - defined once and rolled out to projects. | ||
| - [**Automations**](/automations/custom-automations#create-a-workspace-automation) - workspace-level automations. | ||
|
|
||
| After governance is on, all of these are **workspace-managed**. Projects import and use them. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document all configuration types centralized by governance.
Line 19 says the list contains all centralized configuration, but Line 42 and Line 59 also include templates and recurring work items. Add both items, or change the completeness wording. The current overview omits two configuration types that project admins lose control over.
This conflict is visible within the same page.
Proposed fix
- Enabling governance lifts all of the following from the project level to the workspace level. Each has its own detailed page:
+ Enabling governance lifts the following from the project level to the workspace level:
+- [**Templates**](/templates/project-templates) - shared templates.
+- [**Recurring work items**](/core-concepts/projects/recurring-work-items) - shared recurring work items.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Enabling governance lifts all of the following from the project level to the workspace level. Each has its own detailed page: | |
| - [**States**](/core-concepts/issues/states) - the shared set of states for the whole workspace, including a single workspace triage state. | |
| - [**Workflows and approvals**](/workflows-and-approvals/workflows) - shared workflows that define how work items move between states. | |
| - [**Work item types and custom properties**](/work-items/workspace-work-item-types) - defined once and rolled out to projects. | |
| - [**Automations**](/automations/custom-automations#create-a-workspace-automation) - workspace-level automations. | |
| After governance is on, all of these are **workspace-managed**. Projects import and use them. | |
| Enabling governance lifts the following from the project level to the workspace level: | |
| - [**Templates**](/templates/project-templates) - shared templates. | |
| - [**Recurring work items**](/core-concepts/projects/recurring-work-items) - shared recurring work items. | |
| - [**States**](/core-concepts/issues/states) - the shared set of states for the whole workspace, including a single workspace triage state. | |
| - [**Workflows and approvals**](/workflows-and-approvals/workflows) - shared workflows that define how work items move between states. | |
| - [**Work item types and custom properties**](/work-items/workspace-work-item-types) - defined once and rolled out to projects. | |
| - [**Automations**](/automations/custom-automations#create-a-workspace-automation) - workspace-level automations. | |
| After governance is on, all of these are **workspace-managed**. Projects import and use them. |
🧰 Tools
🪛 LanguageTool
[style] ~19-~19: Consider removing “of” to be more concise
Context: ... centralizes Enabling governance lifts all of the following from the project level to the...
(ALL_OF_THE)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/workspace-administration/workspace-governance.md` around lines 19 - 26,
Update the governance overview around “Enabling governance lifts all of the
following” to include templates and recurring work items, matching the
configuration types described later in the document around lines 42 and 59;
preserve the existing links and descriptions for the other centralized settings.
| 1. The project's **required** workflow, if the type is Required. | ||
| 2. The project's **pin**, if one exists. | ||
| 3. The project's **chosen** workflow (its pick), if set. | ||
| 4. Otherwise, the **workspace default workflow**. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use workspace ownership terminology for Required workflows.
Line 86 calls this “the project’s required workflow,” but Lines 66-72 define Required as a workflow mandated by the workspace. Replace the phrase with “the workspace-mandated workflow” to avoid implying that project administrators own this setting.
This wording conflicts with the ownership model defined earlier on the page.
Proposed fix
-1. The project's **required** workflow, if the type is Required.
+1. The workspace-mandated workflow, if the type is Required.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| 1. The project's **required** workflow, if the type is Required. | |
| 2. The project's **pin**, if one exists. | |
| 3. The project's **chosen** workflow (its pick), if set. | |
| 4. Otherwise, the **workspace default workflow**. | |
| 1. The workspace-mandated workflow, if the type is Required. | |
| 2. The project's **pin**, if one exists. | |
| 3. The project's **chosen** workflow (its pick), if set. | |
| 4. Otherwise, the **workspace default workflow**. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/workspace-administration/workspace-governance.md` around lines 86 - 89,
Update the Required-workflow entry in the workflow precedence list to replace
“the project's required workflow” with “the workspace-mandated workflow,”
preserving the existing ordering and all other terminology.
2 participants
Description
Type of Change
Screenshots and Media (if applicable)
Test Scenarios
References
Summary by CodeRabbit