apply acronix suggestions

Author: petender

learn-pr/wwl-azure/manage-ado-mcp-server/includes/12-guided-exercise-manage-ado-mcp-server.md

@@ -1,7 +1,7 @@
 > [!IMPORTANT]
 > To complete this exercise, you need an active GitHub account, an active GitHub Copilot subscription (Free edition could work, but comes with prompt limitations. You might not be able to go through all prompt steps as defined, depending on your current Copilot consumption), access to an Azure DevOps project and a Visual Studio Code environment.  
 
-This exercise provides a comprehensive experience of using Azure DevOps MCP Server integration in Visual Studio Code with GitHub Copilot, guiding you through several common DevOps team tasks, such as configuring ADO MCP Server in VSCode, interact with Azure Boards work items, retrieve and trigger pipeline runs, inspect logs and monitor Azure DevOps projects and integrate Security guidelines when using MCP. 
+This exercise provides a comprehensive experience of using Azure DevOps MCP Server in Visual Studio Code. You will use GitHub Copilot AI-assistance. Throughout the exercise, you handle several common DevOps team tasks, such as interact with Azure Boards work items, retrieve and trigger pipeline runs. Next, you learn how to use MCP to inspect ADO logs and apply Azure DevOps Security guidelines when using MCP. 
 
 By the end of this lab, you will be able to:
 

learn-pr/wwl-azure/manage-ado-mcp-server/includes/4-authenticate-validate-tools.md

@@ -1,8 +1,8 @@
-Authentication and tool validation are more than onboarding steps. They set the tone for everything that follows. Once you begin using MCP for Azure DevOps tasks, each approval decision becomes part of your operating model. In this unit, the focus is to help you build a pattern that feels practical in daily work: confirm who you are, verify where an action will run, inspect what is being requested, and approve deliberately.
+Authentication and tool validation are more than onboarding steps. They set the tone for everything that follows. Once you begin using MCP for Azure DevOps tasks, each approval decision becomes part of your operating model. In this unit, the focus is to help you build a pattern that feels practical in daily work: confirm who you are, verify where an action runs, inspect what is being requested, and approve deliberately.
 
 ## Why Validation Matters
 
-Conversational workflows are designed to feel fast and natural, but that is exactly why validation discipline matters. When a prompt sounds reasonable, it is easy to move quickly and assume details are correct. Most operational mistakes in this phase are not malicious, they are simple mismatches between intent and scope. A project name is off by one word, a repository reference points to the wrong target, or a write operation is broader than expected. Remember that AI doesn't have a memory state, nor does it has a proper context or reflection, like we humans do have. The more precise you can formulate your prompt, usually the more accurate the action or response will be.
+Conversational workflows are designed to feel fast and natural, but that is exactly why validation discipline matters. When a prompt sounds reasonable, it is easy to move quickly and assume details are correct. Most operational mistakes in this phase are not malicious. They are simple mismatches between intent and scope. A project name is off by one word, a repository reference points to the wrong target, or a write operation is broader than expected. Remember that AI doesn't have a memory state, nor does it has a proper context or reflection, like we humans do have. The more precise you can formulate your prompt, usually the more accurate the action or response is.
 
 Validation is the habit that prevents these small mismatches from becoming real incidents. It gives you confidence that the result you approve is the result you intended, and it helps teams scale AI-assisted workflows without sacrificing control.
 
@@ -14,19 +14,25 @@ After the result returns, compare it with what you expected to see. If the proje
 
 ## Payload Inspection Checklist
 
-Payload inspection - meaning the information you send or receive in the prompt - should feel like a quick quality check, not a heavy process. Before you approve, mentally walk through a few essentials: Is this the right organization? Is this the exact project I intended? Do the IDs and artifact names match what I meant to target? Is the operation type read or write, and is that what I asked for?
+Payload inspection - meaning the information you send or receive in the prompt - should feel like a quick quality check, not a heavy process. 
+
+Before you approve, mentally walk through a few essentials: Ask yourself questions like:
+- Am I connected to the right organization? 
+- Did I connect to the exact project I intended? 
+- Do the work items and artifact names match what I meant to target? 
+- Is the operation type read or write, and is that what I asked for?
 
 The final question is the most important: is the scope as narrow as possible? Narrow scope protects you from unintended side effects, especially in shared environments. This review usually takes only a few seconds, but it dramatically lowers the chance of approving an action with hidden impact.
 
 ## Building Approval Discipline
 
-Strong approval habits develop in stages. Early on, one-time approvals are usually best because they force you to learn how payloads are formed and how prompts map to actions. As your confidence grows, session-level approvals can reduce friction for repetitive, low-risk work. Broader approvals should be treated as an advanced mode, reserved for controlled environments where policy guardrails and team norms are already in place.
+Strong approval habits develop in stages. Early on, one-time approvals are best because they force you to learn how payloads are formed and how prompts map to actions. As your confidence grows, session-level approvals can reduce friction for repetitive, low-risk work. Broader approvals should be treated as an advanced mode, reserved for controlled environments where policy guardrails and team norms are already in place.
 
 If something feels vague or too generic, do not force a decision. Deny, refine the prompt, and run it again with clearer constraints. In practice, a more specific prompt almost always produces a safer and easier-to-review payload.
 
 ## Validate Tool Behavior Across Domains
 
-One successful request is a good start, but it is not enough to trust your full workflow. Validate behavior across the domains you rely on most, such as project discovery, work item lookup, pull request listing, and pipeline status checks. Each domain can expose different permission boundaries, and discovering those boundaries early is much better than finding them during a release window. If you stay within the boundaries of information you are already familiar with, it will also be easier to identify the accuracy of the prompt response.
+One successful request is a good start, but it is not enough to trust your full workflow. Validate behavior across the domains you rely on most, such as project discovery, work item lookup, pull request listing, and pipeline status checks. Each domain can expose different permission boundaries, and discovering those boundaries early is better than finding them during a release window. If you stay within the boundaries of information you are already familiar with, it is easier to identify the accuracy of the prompt response.
 
 ## Common Authentication Issues And Responses
 
@@ -37,15 +43,15 @@ When authentication behaves unexpectedly, the fastest path is usually to verify
 
 ## Security-minded Operating Habits
 
-Security-minded operation is mostly about consistency. Use explicit project names in prompts, avoid broad update requests until you have previewed intent, and treat write approvals as deliberate decisions rather than routine clicks. Keep high-impact actions under human review, especially when prompts involve wide scope or production-adjacent assets.
+Security-minded operation is mostly about consistency. Use explicit project names in prompts, avoid broad update requests until you previewed intent, and treat write approvals as deliberate decisions rather than routine clicks. Keep high-impact actions under human review, especially when prompts involve wide scope or production-adjacent assets.
 
 MCP works best when convenience and caution are balanced. The goal is not to slow work down, but to make correct execution repeatable.
 
 ## Escalation Paths And Exception Handling
 
 Not every failure should trigger a request for broader access. Mature teams separate temporary blockers from true permission gaps. For example, if one repository fails while others succeed, the right fix may be a targeted project assignment rather than organization-wide rights.
 
-When exceptions are necessary, record why the exception exists, how long it should last, and who will review it. This keeps short-term productivity decisions compatible with long-term governance goals.
+When exceptions are necessary, record why the exception exists, how long it should last, and who reviews it. This approach keeps short-term productivity decisions compatible with long-term governance goals.
 
 ## Team Coaching Guidance