s/project-management/how engineering gets work done (Clarify how Eng does stuff and things)

src/_includes/core-nodes/comment-use-case.md

@@ -4,7 +4,7 @@ Adds documentation and explanatory notes directly within your flows.
 
 The Comment node helps document your flows by adding explanatory text that appears on the canvas. This is essential for maintaining flows over time, especially when working in teams or returning to flows after extended periods. By documenting the purpose, requirements, and logic of flow sections, you make flows more understandable, reduce interpretation errors, and speed up troubleshooting and modifications. Comments are particularly valuable for complex flows with link nodes, multi-tab workflows, or business logic that isn't obvious from the nodes alone.
 
-> If you need help documenting your flows, [FlowFuse Assistant](/docs/user/assistant/) can automatically generate documentation with Comment nodes. Simply select your flow and click the "Explain Flow" button, the AI will analyze your flow and create comprehensive documentation that you can add directly to your canvas.
+> If you need help documenting your flows, [FlowFuse Assistant](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant) can automatically generate documentation with Comment nodes. Simply select your flow and click the "Explain Flow" button, the AI will analyze your flow and create comprehensive documentation that you can add directly to your canvas.
 
 ## Modes of operation
 

src/blog/2023/02/3-quick-node-red-tips-2.md

@@ -43,7 +43,7 @@ We hope you found these tips useful, if you'd like to suggest some of your own t
 
 ## Enhance Efficiency with FlowFuse
 
-FlowFuse is a cloud-based platform designed to boost collaboration, security, and scalability for your Node-RED applications. It features [numerous tools and functionalities](/platform/features/) that streamline the development-to-deployment process, including one-click deployment, the [FlowFuse Assistant](/docs/user/assistant/), and other capabilities that simplify managing your Node-RED environment.
+FlowFuse is a cloud-based platform designed to boost collaboration, security, and scalability for your Node-RED applications. It features [numerous tools and functionalities](/platform/features/) that streamline the development-to-deployment process, including one-click deployment, the [FlowFuse Assistant](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant), and other capabilities that simplify managing your Node-RED environment.
 
 For more tips, tricks, and professional development techniques with Node-RED, check out our recommended eBook:
 

src/blog/2023/03/why-should-you-use-node-red-function-nodes.md

@@ -50,7 +50,7 @@ FlowFuse offers a robust platform for building, scaling, and securing your Node-
 
 We are constantly adding new features to make it easy to use in the enterprise where you can rapidly improve your industrial processes. The **"FlowFuse Assistant."** for example is an AI-powered tool that simplifies the creation of Function nodes. You only need to provide a prompt, and the assistant generates the Function nodes for you.
 
-For more details on using the FlowFuse Assistant, visit [the Assistants Documentation](/docs/user/assistant/).
+For more details on using the FlowFuse Assistant, visit [the Assistants Documentation](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant).
 
 ## Conclusion:
 

src/blog/2023/05/chatgpt-nodered-fcn-node.md

@@ -76,7 +76,7 @@ user at the time of the call.
 
 ## FlowFuse Assistant - No API Keys Required!
 
-Great news! You no longer need to manage OpenAI API keys or configure ChatGPT nodes. The [FlowFuse Assistant](/docs/user/assistant/) is now built directly into Node-RED on FlowFuse Cloud, making AI-powered development even easier.
+Great news! You no longer need to manage OpenAI API keys or configure ChatGPT nodes. The [FlowFuse Assistant](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant) is now built directly into Node-RED on FlowFuse Cloud, making AI-powered development even easier.
 
 Available on FlowFuse Cloud, the Assistant offers:
 

src/blog/2023/06/import-modules.md

@@ -64,4 +64,4 @@ Within two minutes, we could wire up a node to retrieve data from our API, and t
 
 With the FlowFuse Assistant, you can leverage AI to generate Function nodes effortlessly. Just input your prompt, and the Assistant will handle the creation for you, saving time and reducing manual coding.
 
-To explore how to make the most of the FlowFuse Assistant and its capabilities, check out the [Assistants Documentation](/docs/user/assistant/).
+To explore how to make the most of the FlowFuse Assistant and its capabilities, check out the [Assistants Documentation](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant).

src/blog/2025/07/connect-legacy-equipment-serial-flowfuse.md

@@ -175,7 +175,7 @@ This transforms the string into a JSON object like:
 ```
 
 > **Tip**: You do not need to know JavaScript to use the **function** node.
-> If you are using FlowFuse, the built-in [FlowFuse Assistant](https://www.google.com/search?q=/docs/user/assistant/) can help you write function code using natural language. Simply provide a sample of the data received from your machine and describe the output you expect — the Assistant will generate the function for you.
+> If you are using FlowFuse, the built-in [FlowFuse Assistant](/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant) can help you write function code using natural language. Simply provide a sample of the data received from your machine and describe the output you expect — the Assistant will generate the function for you.
 
 ### Handling Request-Response Serial Communication
 

src/blog/2025/12/flowfuse-release-2-25.md

@@ -38,7 +38,7 @@ Previously, this was only available in Node-RED managed directly by the FlowFuse
 
 You will need an account on FlowFuse Cloud to connect it to, but for this release, it does *not* require a paid subscription to use.
 
-Check the FlowFuse Expert Assistant docs for [how to get started](https://flowfuse.com/docs/user/assistant/#flowfuse-assistant-plugin).
+Check the FlowFuse Expert Assistant docs for [how to get started](https://flowfuse.com/handbook/development/ops/self-hosted-assistant/#flowfuse-assistant-plugin).
 
 ## Improved Update Scheduling
 ![Image of Scheduled Updates UI](./images/updates.png)

src/handbook/development/how-engineering-gets-work-done.md

@@ -0,0 +1,289 @@
+---
+navTitle: How Engineering Gets Work Done
+---
+
+# How Engineering Gets Work Done
+
+## Overview
+
+Engineering at FlowFuse operates through a small set of intentional weekly rhythms.
+
+These rhythms help us:
+
+* surface what matters
+* align on shared understanding
+* commit to work realistically
+* support engineers as they execute
+
+Meetings, boards, and labels exist to support this workflow, not replace judgment or collaboration.
+
+## TL;DR
+
+* Engineering work is guided by clear weekly rhythms, not ad hoc urgency.
+* The Monday engineering meeting is the highest-level forum for alignment and discussion.
+* Sprint planning (Friday) is where we commit to already-prioritized work and assign timeboxes.
+* Each engineer commits to 24 hours of timeboxed work per sprint.
+* Issue labels make work visible and sprint-ready; anything in a sprint must be fully labeled.
+* We are async-first, but pragmatic about using sync time when it helps.
+
+## Cadence
+
+Engineering work follows a consistent weekly cadence designed to create alignment and focus.
+
+That cadence is anchored by two core meetings:
+
+* the Monday Engineering Meeting
+* Sprint Planning on Friday
+
+## Weekly Engineering Meeting (Monday)
+
+The Monday engineering meeting is the highest-level forum for alignment and discussion.
+
+It is dedicated engineering time to talk through what is top of mind for the team, share context, and surface concerns that need collective attention.
+
+This meeting is not about status or reporting. It exists to ensure the team starts the week on the same page.
+
+Notes and agenda live in a running Google Doc shared with the team.
+
+### Agenda & Preparation
+
+The meeting follows a lightweight, repeatable agenda inspired by the Bloom meeting format, typically including:
+
+* headlines
+* goals
+* issues to discuss
+* follow-ups or todos
+
+Before the meeting:
+
+* engineers add topics they want to discuss to the issues list in the agenda document
+* topics should include enough context for others to understand why they matter
+
+This ensures the agenda reflects real concerns, not just the loudest voices.
+
+### Issue Selection & Discussion
+
+At the start of the meeting:
+
+* engineers vote on which issues to discuss
+* issues are discussed in order of most votes first
+
+This makes priority explicit and shared.
+
+### Timeboxing & Carryover
+
+* Every agenda item is timeboxed.
+* When time expires, discussion stops.
+* Unfinished topics carry over to the next meeting.
+
+This keeps the meeting focused and protects collective time.
+
+## Sprint Planning (Friday)
+
+Sprint planning is a one-hour weekly meeting, typically held on Fridays (or the last business day of the week if there is a holiday).
+
+This is where engineering commits to work.
+
+Sprint planning has two goals:
+
+1. Close the sprint that is finishing
+2. Commit work for the sprint that begins the next business day
+
+### Closing the Current Sprint
+
+We review:
+
+* what was completed
+* what was not
+* whether any work is overflowing into the next sprint
+
+The project board is updated to reflect reality. This is about accuracy and learning, not blame.
+
+## Development Board
+
+We use a GitHub Project board to make work visible and to reflect sprint reality.
+
+The board shows what work is in progress, what is blocked, and what has shipped.
+
+It is updated during sprint planning and throughout the week as work progresses.
+
+### Prioritization Happens Outside Sprint Planning
+
+Sprint planning is not a prioritization meeting.
+
+Prioritization happens elsewhere, in conversations involving:
+
+* Product
+* Engineering Management
+* the CTO
+
+Sprint planning assumes this work has already been prioritized.
+
+If new priorities surface during sprint planning, they are handled outside the meeting and brought back later.
+
+### Planning the Next Sprint
+
+During sprint planning:
+
+* engineers select from already-prioritized work
+* scope is confirmed
+* timeboxes are assigned
+* blockers and dependencies are surfaced
+* work is committed or deferred
+
+Each engineer commits to up to 24 hours of timeboxed work per sprint.
+
+Timeboxes represent expected effort, not performance targets.
+
+## Feature Demos
+
+Completing a meaningful piece of work often includes demonstrating it.
+
+Feature demos help to:
+
+* share context across the team
+* validate that work delivers the intended value
+* surface gaps or follow-up ideas early
+* support release communication and storytelling
+
+Demos should be lightweight and timely.
+
+If questions, issues, or improvement ideas come up during a demo, they should be captured as GitHub issues and planned like any other work.
+
+## Changelog & Release Communication
+
+Some completed work is communicated externally via the FlowFuse changelog and release highlights.
+
+Work may be changelog-worthy when it:
+
+* delivers visible user value
+* introduces new functionality or behavior
+* significantly improves an existing workflow
+* fixes an impactful or user-facing bug
+
+Ownership of publishing changelog entries may evolve over time. Regardless of ownership, engineering is responsible for surfacing notable work and relevant context.
+
+### Communicating Highlights to Product & Marketing
+
+Engineering shares release highlights through the standing Product ↔ Marketing Sync, a fortnightly meeting held during weeks 2 and 4 of the release cycle.
+
+The Engineering Manager represents engineering in this meeting.
+
+Issue labels are used to help Engineering Managers identify which completed or in-flight items may be relevant to share.
+
+## Issue Labels (How We Make Work Visible)
+
+Issue labels are a shared contract that support planning and execution.
+
+From the labels alone, an engineer should be able to understand:
+
+* what kind of work an issue represents
+* where it lives in the system
+* how much effort it is expected to take
+* whether it is ready to be worked
+
+### When Labels Are Applied
+
+* Labels are applied before and during sprint planning.
+* Sprint planning is where labeling is finalized.
+* Any issue committed to a sprint must be fully labeled.
+
+If required information is missing, the issue is not ready to be worked.
+
+### Effort & Timeboxing
+
+Timeboxes indicate expected effort, not complexity or importance.
+
+* Timeboxes are intentionally small.
+* Work larger than a few hours must be broken down.
+* Unclear work is marked explicitly.
+
+## Defining Done
+
+An issue is considered done when it is merged and deployed, and any required follow-up (documentation, validation, or release communication) is complete.
+
+If work is not shipped or not validated, it is not done.
+
+## Ad Hoc Collaboration (Async-First, Flexible)
+
+Engineering at FlowFuse is async-first by default.
+
+We prefer written context, Slack threads, issues, and docs that preserve focus time.
+
+At the same time, we are pragmatic and flexible.
+
+Engineers are encouraged to use quick Slack huddles, pairing sessions, or short syncs when they are the fastest way to unblock work or align.
+
+## Worked Example
+
+### Scenario
+
+A recurring issue where Node-RED flows sometimes fail to deploy after an upgrade.
+
+### Monday Engineering Meeting
+
+* An engineer adds the topic to the agenda issues list with brief context.
+* The team votes and discusses the issue.
+* The group agrees it needs investigation, but scope is unclear.
+
+No sprint commitment is made. The meeting creates alignment, not assignments.
+
+### Issue Creation
+
+A GitHub issue is created with:
+
+* a clear work item type
+* a single work type
+* relevant area labels
+* time:TBD
+
+The issue is visible but intentionally not sprint-ready.
+
+### Sprint Planning
+
+* The work has been prioritized outside sprint planning.
+* During planning, the team agrees to break it into smaller tasks.
+* An investigation task is created, timeboxed, and pulled into the sprint.
+
+### Execution
+
+* The investigation task is worked.
+* Any additional work discovered is brought back through planning.
+
+This keeps work small, explicit, and intentional.
+
+## How the Pieces Fit Together
+
+* The Monday engineering meeting builds alignment and shared understanding.
+* Sprint planning commits to a realistic slice of already-prioritized work.
+* Issue labels make that work explicit and visible.
+* Async-first collaboration supports day-to-day execution.
+
+Together, these create a system that favors clarity over urgency, small work over heroic effort, and shared understanding over silent assumptions.
+
+## Engineering KPIs
+
+These metrics help us observe how well the engineering system described above is functioning over time.
+
+They are used to understand trends and surface constraints, not to evaluate individual performance or enforce targets.
+
+## Engineering Throughput
+
+We no longer use Engineering Throughput as a primary metric.
+
+Instead, we track Engineering Time to Value (median and P75) and ticket type distribution to understand delivery speed and bottlenecks.
+
+### Engineering Time to Value (Median)
+
+**TL;DR**  
+How long a typical piece of engineering work takes to go from started to done.
+
+### Engineering Time to Value (P75)
+
+**TL;DR**  
+How long the slowest 25% of engineering work takes to go from started to done.
+
+### Ticket Type Distribution
+
+**TL;DR**  
+The ratio of feature work to other work (bugs, chores, maintenance).