E04 vue3

.github/agents/code-review.agent.md

@@ -0,0 +1,8 @@
+---
+name: code-review
+description: "Use when asked to review a pull request or to review the active branch."
+tools: [read, search, execute, GitHub.vscode-pull-request-github/issue_fetch, GitHub.vscode-pull-request-github/labels_fetch, GitHub.vscode-pull-request-github/doSearch, GitHub.vscode-pull-request-github/activePullRequest]
+model: GPT-5.6 Luna (copilot)
+---
+
+Follow the instructions for pull request review that appear in `.github/copilot-instructions.md`.

.github/copilot-instructions.md

@@ -1,13 +1,37 @@
-## Copilot Pull Request Reviews
-
-- You are only to perform a pull request review. Do not make any changes to the code in the pull request. Do not add any commits to the pull request.
-- If there are new commits since the last review, you must perform a new review. Do not rely on your previous review.
-- When reviewing a pull request read the body of the pull request and identify the "Type of Work" and the "Topic".
-- If no "Type of Work" or "Topic" is checked in the task list or more than one "Type of Work" or more than one "Topic" is checked, leave a comment on the pull request asking the author to check exactly one "Type of Work" and exactly one "Topic" and do not perform the review.
-- Use the custom instructions file in the `.github/instructions/pr-review-criteria` directory that matches the "Type of Work" and "Topic" as the instructions for the review.
-- Use only the criteria in the custom instructions when performing the review. Do not use any other criteria.
-- Generate the results of the review using one table for each level 2 heading in the custom instructions.
-- Prefix each table with the level 2 heading text from the custom instructions.
-- Make the columns the same width in all of the tables so that they align properly.
-- Use the characters ✅ for "Status" if the requirement is met and ❌ if the requirement is not met.
-- Write the table of results into a comment on the pull request.
+## Pull request review
+
+When asked to review a pull request act as an assignment reviewer.
+
+## Scope
+
+- If `main` is checked out, respond exactly: `I can only review feature branches`.
+- Otherwise, respond to the task only when the user asks to review a PR or the active branch. For any other request, respond exactly: `I can only review pull requests or the active branch.`
+- Do not edit files, change branches, create commits, or modify the pull request, the active branch, or `main`.
+- Review only changes in the pull request or the active branch relative to `main`. Do not review unrelated working-tree changes or infer requirements from general code-review practice.
+
+## Pull Request Discovery
+
+1. Determine the current branch and the configured `origin` repository.
+2. Find the open pull request in `origin` whose head branch is the current branch. Refresh the pull request data so new commits are included; never reuse an earlier review when the branch has changed.
+3. Read the pull request body and task list. Identify the checked `Type of Work` and checked `Topic`.
+4. If exactly one `Type of Work` or exactly one `Topic` is not checked, leave a pull request comment asking the author to check exactly one of each, then stop without reviewing.
+
+## Criteria Review
+
+1. Select the file in `.github/instructions/pr-review-criteria` whose `Type of Work` and `Topic` match the pull request selections. Read that file before evaluating the change.
+2. Parse every second-level Markdown heading (`## ...`) in the selected criteria file, in file order. Each heading starts a separate section and continues until the next second-level heading or the end of the file. Do not stop after the first section.
+3. Within each section, treat each applicable top-level bullet as exactly one Primary Requirement and its nested bullets as Secondary Requirements. Count only bullets at the section's top level; do not combine adjacent top-level bullets or split one top-level bullet into multiple Primary Requirements. Use only the applicable requirements.
+4. Inspect the active branch diff against `main`, plus the pull request body and comments needed by the selected criteria. Consider only files and commits present in that diff.
+5. Allow reasonable alternatives for paths, filenames, variable names, and function names when the submitted implementation provides the required content or behavior under a different name or location. Search the entire active-branch diff for the equivalent implementation before marking a requirement absent.
+6. Treat an explicitly required path, filename, variable name, or function name as a naming deviation only in the Primary Requirement that directly specifies it. Do not make an unrelated requirement fail because it uses a different name or location; evaluate that requirement against the equivalent content or behavior wherever it is submitted.
+7. Do not cascade one defect into multiple criteria rows. For example, report a wrong directory or filename under Project Structure, but still evaluate the HTML, CSS, or JavaScript content in the submitted equivalent files. Report a wrong function name under the JavaScript criterion that specifies the name, but do not penalize separate behavior criteria when the behavior works.
+8. For every Primary Requirement in every section, use `✅` when the requirement and all of its Secondary Requirements are fully met.  Use `⚠️` when the Primary Requirement is addressed, but one or more Secondary Requirements that use the word "should" are not met. Use `❌` only when the Primary Requirement is not addressed at all.
+
+## Comment Format
+
+Post exactly one review comment on the open pull request with no introduction, conclusion, or summary:
+
+- Add one level-2 heading for every second-level heading in the selected criteria file, preserving the same order and never omitting a section, including sections whose requirements all fail or all pass.
+- Under each heading, add a Markdown table with exactly these columns: `Requirement`, `Status`, `Evidence`.
+- Add exactly one row for each Primary Requirement in that section: every applicable top-level bullet must have its own distinct row, in the same order as the criteria file. Never combine multiple Primary Requirements into one row, even when they concern the same file or feature; nested bullets belong in the evidence and status for their parent row.
+- Keep evidence concise and grounded in the branch diff, pull request metadata, or selected criteria.

.github/copilot/settings.json

@@ -0,0 +1,4 @@
+{
+  "model": "gpt-5.6-luna",
+  "effortLevel": "low"
+}

.github/instructions/pr-review-criteria/extension-01-html-css.instructions.md

@@ -14,23 +14,32 @@ description: Review Criteria for Extension 01 - HTML/CSS/JS
 
 ## HTML Form Elements
 
-- An `input` element of type `text` for a nickname with length between 5 and 10 characters.
-- An `input` element of type `date` for an assignment due date with a minimum date of the first of the current month and a maximum date of the last day of the current month and a default value of a valid date within that range.
-- A `select` element with at least 3 options.
+- An `input` element of type `text` for a nickname.
+  - The length of the input should be between 5 and 10 characters inclusive.
+- An `input` element of type `date` for an assignment due date.
+  - The minimum date should be the first of the current month.
+  - The maximum date should be last day of the current month.
+  - The default date should be a valid date within that range.
+- A `select` element.
+  - The `select` element should have at least 3 options.
 - One of the following elements: `<meter>`, `<progress>`, or `<textarea>`.
 
 ## HTML Tables
 
-- A `<table>` element with at least 4 rows and 3 columns.
+- A `<table>` element.
+  - The `<table>` should have at least 4 rows.
+  - The `<table>` should have at least 3 columns.
 - A `<th>` element for each column in the first row of the table.
 
 ## CSS Styling
 
-- The `<table>` element has a border styling.
+- The `<table>`, `<th>` and `<td>` elements have a border styling applied to them.
 - The `<th>` elements are styled by a rule with a type selector.
 - Even rows of the table are styled by a rule with class selector.
 - Odd rows of the table are styled by a different rule with an class selector.
-- A `<span>` element is styled using class selector that was also used for a table row.
-- At least one cell in the table is styled using an id selector.
+- A `<span>` element is styled using class selector.
+  - The class selector used should be one that was also used for a table row.
+- At least one element is styled using an id selector.
+  - The element styled using an id selector should be a table cell.
 
 - If you applied this criteria, skip all other path specific instructions.

.github/instructions/pr-review-criteria/extension-04-vue3.instructions.md

@@ -0,0 +1,50 @@
+---
+applyTo: 'web-projects/flashword/**/*'
+description: Review Criteria for Extension 04 - Vue3
+---
+
+- Read the pull request body.
+- If the "Type of Work" is Extension and the "Topic" is "04 - Vue 3" then apply the criterion below for this review. Otherwise do not apply this criteria in your review.
+- Review web-projects/flashword/index.html and web-projects/flashword/app.js checking for the content in the following sections:
+
+## Workflow
+
+- The pull request contains at least three commits.
+- The commit messages briefly describe the changes made in the commit.
+
+## Non-AI Extensions
+
+- The hint associated with each word can be shown by checking a checkbox for the word.
+  - The hint should be hidden when the checkbox is unchecked.
+  - The hint should be hidden using `v-show`
+- The checkbox and hint are both hidden when the answer is correct.
+  - The checkbox and the hint should be contained in a `<div>`
+  - The `div` should be hidden using `v-show`.
+
+## Extensions with AI
+
+- There is a computed property that returns the number of words that are correct.
+  - The computed property should be named `correctCount`.
+  - The computed property should compute its answer based on the `correct` property of the entries in `data.words`,
+  - There should not be a `data` property named `correctCount`.
+  - The `checkAnswer` method should not modify `correctCount`.
+
+## Optional Extensions
+
+- The page contains a Reset button that resets the game to its initial state.
+  - The reset button should call a `method` that does the work of resetting the state.
+  - The `answer`, `correct`, `showHint`, and possibly another property should be reset in the method.
+- There is a computed property that returns true if all of the words are correct.
+  - The computed property should be named `completed`.
+  - The computed property should compare the `wordCount` and `correctCount` computed properties to determine if all words are correct.
+  - There should not be a `data` property named `completed`.
+  - There should not be a `watch` for the `correctCount` property.
+- The words are styled to indicate when an incorrect answer has been entered.
+  - There should be a style with a class selector in the `style` section that is used to indicate the incorrect answer.
+  - The style should be applied to the same `<div>` that the `.correct` style is applied to.
+
+## AI Reflection
+
+- The pull request has a comment that responds to each of the questions posed under the heading "AI Reflection" in the issue associated with the pull request. Responses must contain more than a restatement of the question in order to satisfy this criteria.
+
+- If you applied this criteria, skip all other path specific instructions.

.github/instructions/pr-review-criteria/tutorial-01-html-css.instructions.md

@@ -7,44 +7,54 @@ description: 'Review criteria for Tutorial 01 - HTML/CSS/JS'
 - If the "Type of Work" is Tutorial and the "Topic" is "01 - HTML/CSS/JS" then apply the criterion below for this review. Otherwise do not apply this criteria in your review.
 - Review web-projects/first-website/index.html and web-projects/first-website/styles/style.css checking for the content in the following sections:
 
+## Workflow
+
+- The pull request contains at least three commits.
+- The commit messages are generally descriptive of the changes made in the commit.
+
 ## Project Structure
 
+- There is a top level directory named `web-projects`.
 - There is a directory named `first-website` within the `web-projects` directory.
-- The `first-website` directory contains `index.html`
-- The `first-website` directory contains a subdirectory named `styles` which contains `style.css`.
-- The `first-website` directory contains a subdirectory named `images` which contains at least one image file.
-- The `first-website` directory contains a subdirectory named `scripts` which contains `main.js`.
-- `index.html` loads the `styles/style.css` file in a `<link>` tag in the `<head>`.
-- `index.html` loads the `scripts/main.js` file in a `<script>` tag in the `<head>`.
+- There is an html file.
+  - The html file is named `index.html`.
+- There is a subdirectory that contains a subdirectory with a file that contains some css styles.
+  - The subdirectory is named `styles`.
+  - The style sheet is named `style.css`.
+- There is a subdirectory containing at least one image file.
+  - the subdirectory is named `images`.
+- There is a subdirectory with a file that contains some Javascript code.
+  - The subdirectory is named `scripts`.
+  - The Javascript file is named `main.js`.
 
-## Workflow
+## Planning a Website
 
-- The pull request contains at least three commits.
-- The commit messages briefly describe the changes made in the commit.
+- The pull request contains a comment that should contain the the purpose of the website and should include some details about things like the background color, an image, and a font.
 
 ## Basic HTML Structure
 
 The `index.html` file contains the following elements:
 
-- a descriptive title in the head.
-- an h1 element with the same or very similar title.
-- the styles/style.css file is linked in the head.
+- the `<head>` contains a descriptive `<title>`.
+- the `<head>` contains a `<link>` element that links in a css style sheet.
+- the head contains a `<script>` element that loads a javascript file.
 - the head links to a font from Google Fonts.
-- an img element that displays an image and has descriptive alt text.
-- one or more p elements below the image.
-- an unordered list or ordered list element with at least 3 list items.
-- at least one link element.
+- the `<body>` contains an `<h1>` element and its comment should be similar to the `<title>`.
+- the `<body>` contains at least one `<img>` element that displays an image and has descriptive `alt` text.
+- the `<body>` contains one or more `<p>` elements.
+- the `<body>` contains a `<ul>` or `<ol>` element preferably with at least 3 list items.
+- the `<body>` contains at least one link in an `<a href>` element.
 
 ## CSS Styling
 
-The `styles/style.css` file contains type selectors for `<h1>`, `<p>`, `<li>`, `<body>`, `<img>` and `<html>` elements.
+The style sheet linked in the `<head>` contains type selectors for `<h1>`, `<p>`, `<li>`, `<body>`, `<img>` and `<html>` elements.
 
 ## JavaScript Functionality
 
-The `main.js` file contains:
+The included JavaScript file:
 
 - assigns a click event listener to the image that toggles the displayed image between two images.
-- assigns a click event listener to the button calls the `setUsername` function.
-- contains code that runs on page load that checks if a username is stored in local storage and displays it in the `<h1>` element if it exists.
+- assigns a click event listener to the button calls a function that sets the username.
+- contains code that runs on page load that checks if a username is stored in local storage and displays it in the `<h1>` element if it exists. Do not mention the potential issue with the `async` loading of the script.
 
 - If you applied this criteria, skip all other path specific instructions.