updates to git ignore

Author: s-polly

.github/copilot-instructions.md

@@ -0,0 +1,101 @@
+# Copilot Instructions
+
+This file provides central guidance for GitHub Copilot in this repository.
+
+This documentation repository contains Microsoft's technical documentation for application development using Microsoft Azure AI Foundry (and other products) that publishes to Microsoft Learn. 
+
+
+## Referenced Instruction Files
+
+•	.github/instructions/foundry-branding.instructions.md
+•	.github/instructions/dev-focused.instructions.md
+ 
+## Disclosure
+
+For any Markdown files modified by AI, always disclose that they were created with the assistance of AI. Add the following frontmatter key/value pair:
+
+ai-usage: ai-assisted
+
+## Content Verification Rules
+
+- DO NOT invent or fabricate technical details, API parameters, or service capabilities.
+- DO NOT create fictional code examples or imaginary features.
+- DO NOT hallucinate or assume facts not found in official or credible documentation.
+- ALWAYS check specification documents and official references before making suggestions.
+- When a recommendation is based on another instruction file or linked source, cite it inline (for example: “(Source: edit_instructions.md)”).
+- If required information is missing or unclear, insert a placeholder with `[TO VERIFY]`—do not guess.
+
+##  Writing Style
+
+Follow Microsoft Writing Style Guide (https://learn.microsoft.com/en-us/style-guide/welcome/) with these specifics:
+
+### Voice and Tone
+
+•	Active voice, second person addressing reader directly.
+•	Conversational tone with contractions.
+•	Present tense for instructions/descriptions.
+•	Imperative mood for instructions ("Call the method" not "You should call the method").
+•	Use "might" instead of "may" for possibility.
+•	Use "can" instead of "may" for permissible actions.
+•	Avoid "we"/"our" referring to documentation authors or product teams.
+
+### Pattern compliance
+
+-	Articles should comply with the pattern for the ms.topic type listed in the metadata
+    - `how-to-guide` - refer to .github/patterns/How-to-template.md
+    - `quickstart` - refer to .github/patterns/Quickstart-template.md
+    - `tutorial` - refer to .github/patterns/Tutorial-template.md
+
+Instructions for the pattern are contained in comments in the referenced file.
+
+## Structure and Format
+
+- Use sentence case for titles and headings; avoid gerunds in titles.
+- Keep paragraphs short (1–3 sentences).
+- Break up or rewrite long sentences (>25 words).
+- Use the Oxford comma in lists.
+- Number ordered list items using `1.` for each line (Markdown auto-numbers).
+- List items should be complete sentences when longer than a short phrase; end with a period if a sentence.
+- Avoid “etc.” or “and so on.” Use “for example” with a concrete subset or provide the full list.
+- Use “for example” instead of “e.g.”; “that is” instead of “i.e.”.
+- Don’t stack headings without intervening explanatory text.
+- Keep conceptual explanation separate from procedural steps.
+- Reserve troubleshooting for a clearly labeled section when needed.
+ 
+## Formatting Conventions
+
+- Bold: UI labels and visible button or menu text.
+- Code style (backticks): file names, folders, inline code, commands, class and method names, non-localizable tokens.
+- Use relative links for repo-local files.
+- Use angle brackets around raw URLs only when the plain URL must be shown.
+- Present tense only; rewrite future tense (“will create”) to present (“creates” / “creates a resource”).
+- Prefer gender-neutral language; avoid idioms and metaphors.
+- Tables only when they improve scan-ability (parameters, comparisons).
+ 
+## File Naming
+
+- New Markdown files: lowercase, hyphen-separated.
+- Omit filler words (the, a, an, of) unless needed for clarity.
+- Keep names task- or concept-focused (for example: `monitor-model-performance.md`).
+
+
+## Referencing sources
+
+When basing content on:
+- Internal instruction files: cite the filename inline.
+- External docs (public): use a relative or official Microsoft Learn link.
+If uncertain about a claim, mark it `[TO VERIFY]`.
+
+## Change boundaries
+
+- Don’t alter original meaning unless the task explicitly requests it.
+- Safe edits: clarity, consistency, formatting, style compliance, verified corrections.
+
+
+## General guidance
+
+- Always re-check `.github/instructions/` before large edits.
+- Keep diffs focused; avoid opportunistic large-scale refactors unless requested.
+- Consolidate repetitive phrasing where possible for readability.
+- Align with current product branding from `foundry-branding.instructions.md`.
+ 

.github/patterns/Concept-template.md

@@ -0,0 +1,155 @@
+---
+title: #Required; Keep the title body to 60-65 chars max including spaces and brand
+description: #Required; Keep the description within 100- and 165-characters including spaces 
+author: #Required; your GitHub user alias, with correct capitalization
+ms.author: #Required; microsoft alias of author
+ms.service: #Required; use the name-string related to slug in ms.product/ms.service
+ms.topic: concept-article #Required; leave this attribute/value as-is.
+ms.date: #Required; mm/dd/yyyy format.
+
+#CustomerIntent: As a <type of user>, I want <what?> so that <why?>.
+---
+
+<!--
+Remove all the comments in this template before you sign-off or merge to the  main branch.
+
+This template provides the basic structure of a Concept article pattern. See the [instructions - Concept](../level4/article-concept.md) in the pattern library.
+
+You can provide feedback about this template at: https://aka.ms/patterns-feedback
+
+Concept is an article pattern that defines what something is or explains an abstract idea.
+
+There are several situations that might call for writing a Concept article, including:
+
+* If there's a new idea that's central to a service or product, that idea must be explained so that customers understand the value of the service or product as it relates to their circumstances. A good recent example is the concept of containerization or the concept of scalability.
+* If there's optional information or explanations that are common to several Tutorials or How-to guides, this information can be consolidated and single-sourced in a full-bodied Concept article for you to reference.
+* If a service or product is extensible, advanced users might modify it to better suit their application. It's better that advanced users fully understand the reasoning behind the design choices and everything else "under the hood" so that their variants are more robust, thereby improving their experience.
+
+-->
+
+<!-- 1. H1
+-----------------------------------------------------------------------------
+
+Required. Set expectations for what the content covers, so customers know the content meets their needs. The H1 should NOT begin with a verb.
+
+Reflect the concept that undergirds an action, not the action itself. The H1 must start with:
+
+* "\<noun phrase\> concept(s)", or
+* "What is \<noun\>?", or
+* "\<noun\> overview"
+
+Concept articles are primarily distinguished by what they aren't:
+
+* They aren't procedural articles. They don't show how to complete a task.
+* They don't have specific end states, other than conveying an underlying idea, and don't have concrete, sequential actions for the user to take.
+
+One clear sign of a procedural article would be the use of a numbered list. With rare exception, numbered lists shouldn't appear in Concept articles.
+
+-->
+
+# [\<noun phrase\> concept(s)]
+TODO: Add your heading
+
+<!-- 2. Introductory paragraph
+----------------------------------------------------------
+
+Required. Lead with a light intro that describes what the article covers. Answer the fundamental "why would I want to know this?" question. Keep it short.
+
+* Answer the fundamental "Why do I want this knowledge?" question.
+* Don't start the article with a bunch of notes or caveats.
+* Don't link away from the article in the introduction.
+* For definitive concepts, it's better to lead with a sentence in the form, "X is a (type of) Y that does Z."
+
+-->
+
+[Introductory paragraph]
+TODO: Add your introductory paragraph
+
+<!-- 3. Prerequisites --------------------------------------------------------------------
+
+Optional: Make **Prerequisites** your first H2 in the article. Use clear and unambiguous
+language and use a unordered list format. 
+
+-->
+
+## Prerequisites
+TODO: [List the prerequisites if appropriate]
+
+<!-- 4. H2s (Article body)
+--------------------------------------------------------------------
+
+Required: In a series of H2 sections, the article body should discuss the ideas that explain how "X is a (type of) Y that does Z":
+
+* Give each H2 a heading that sets expectations for the content that follows.
+* Follow the H2 headings with a sentence about how the section contributes to the whole.
+* Describe the concept's critical features in the context of defining what it is.
+* Provide an example of how it's used where, how it fits into the context, or what it does. If it's complex and new to the user, show at least two examples.
+* Provide a non-example if contrasting it will make it clearer to the user what the concept is.
+* Images, code blocks, or other graphical elements come after the text block it illustrates.
+* Don't number H2s.
+
+-->
+
+## [Section 1 heading]
+TODO: add your content
+
+## [Section 2 heading]
+TODO: add your content
+
+## [Section n heading]
+TODO: add your content
+
+<!-- 5. Next step/Related content ------------------------------------------------------------------------ 
+
+Optional: You have two options for manually curated links in this pattern: Next step and Related content. You don't have to use either, but don't use both.
+  - For Next step, provide one link to the next step in a sequence. Use the blue box format
+  - For Related content provide 1-3 links. Include some context so the customer can determine why they would click the link. Add a context sentence for the following links.
+
+-->
+
+## Next step
+
+TODO: Add your next step link(s)
+
+> [!div class="nextstepaction"]
+> [Write concepts](article-concept.md)
+
+<!-- OR -->
+
+## Related content
+
+TODO: Add your next step link(s)
+
+- [Write concepts](article-concept.md)
+
+<!--
+Remove all the comments in this template before you sign-off or merge to the main branch.
+-->
+
+
+<!-- 6. Next step/Related content ------------------------------------------------------------------------
+
+Optional: You have two options for manually curated links in this pattern: Next step and Related
+content. You don't have to use either, but don't use both. For Next step, provide one link to the
+next step in a sequence. Use the blue box format For Related content provide 1-3 links. Include some
+context so the customer can determine why they would click the link. Add a context sentence for the
+following links.
+
+-->
+
+## Next step
+TODO: Add your next step link(s)
+> [!div class="nextstepaction"]
+> [Write concepts](article-concept.md)
+
+<!-- OR -->
+
+## Related content
+TODO: Add your next step link(s)
+- [Write concepts](article-concept.md)
+
+<!--
+Remove all the comments in this template before you sign-off or merge to the 
+main branch.
+
+-->