|
|
@@ -1,125 +0,0 @@
|
|
|
-Vision statement
|
|
|
-A local food AI that provides full nutritional value information on any food and can
|
|
|
-generate complete menu proposals based on the user's specification.
|
|
|
-The user can:
|
|
|
-* Create an account and log in.
|
|
|
-* Get complete nutritional value information on any food, including macro nutrients,
|
|
|
-minerals, vitamins, amino acids etc.
|
|
|
-* Get the full nutritional value information for a given food combination, i.e. the user can
|
|
|
-enter the quantities of several foods and get a full nutritional value overview.
|
|
|
-* Search for specific nutrient content and get a sortable list of all foods that contain
|
|
|
-this/these nutrient(s).
|
|
|
-* Store food combinations in named and editable lists.
|
|
|
-* Get menu proposals based on nutritional value and other food constraint input, e.g.
|
|
|
-allergies.
|
|
|
-* Freely chat about anything related to nutrition and get competent answers.
|
|
|
-* The AI must have a local web search tool that it will use to anonymously gather any
|
|
|
-info that it does not have in its local database.
|
|
|
-* No user data leaves the server.
|
|
|
-* The whole project must be in a public listed https://git.btshub.lu repo
|
|
|
-named LocalFoodAI_<your IAM> that is updated in real-time. Make sure to prevent
|
|
|
-confidential data from being uploaded. Add your teacher (id evegi144) as a collaborator.
|
|
|
-Anyone should be able to clone the repo and get his own local food AI running with
|
|
|
-ease.
|
|
|
-* The application must be designed to run entirely on your provided Ubuntu 24.04 VM (8
|
|
|
-vCPUs, 30 GB RAM, no dedicated GPU). You must evaluate and select appropriate
|
|
|
-lightweight, quantized local LLMs (via Ollama) and databases that fit securely within
|
|
|
-this hardware limit.
|
|
|
-Roles
|
|
|
-• You are the product owner and tech lead, whilst Antigravity is your development
|
|
|
-team. This means that you interview the customer to extract the vision, and then
|
|
|
-write the Taiga backlog.
|
|
|
-• Your teacher is the customer and Scrum master. Add your teacher
|
|
|
-(gilles.everling@education.lu) as a stakeholder to your Taiga project.
|
|
|
-Workflow
|
|
|
-• You follow the Scrum manual.
|
|
|
-• You agree on the meaning of "Done" with your teacher.
|
|
|
-• The sprint time box is one week.
|
|
|
-• All meetings are documented in the Wiki.
|
|
|
-• In the Daily Scrum meeting you answer and document in the Wiki the three
|
|
|
-questions:
|
|
|
-o What has been accomplished since the last meeting?
|
|
|
-o What will be done before the next meeting?
|
|
|
-o What obstacles are in the way?
|
|
|
-• Thursday:
|
|
|
-o Sprint Review meeting that lasts at most 15 minutes.
|
|
|
-o Sprint Retrospective meeting that lasts at most 15 minutes.
|
|
|
-o Sprint Planning meeting that lasts at most 30 minutes. You estimate the
|
|
|
-capacity of work, produce the Sprint Backlog and Sprint Goal.
|
|
|
-o Daily Scrum meeting that lasts at most 5 minutes.
|
|
|
-• Friday:
|
|
|
-o Daily Scrum meeting that lasts at most 5 minutes.
|
|
|
-• You perform continuous product backlog grooming.
|
|
|
-• During Sprint Planning, you create User Stories in Taiga and break them down
|
|
|
-into smaller technical Tasks. To execute the work, you feed the overarching User
|
|
|
-Story to the agent for context, but you assign it the specific Task for execution.
|
|
|
-• Before the agent writes the code, it generates an Implementation Plan (an
|
|
|
-Antigravity Artifact). You must set your Antigravity Review Policy to "Request
|
|
|
-Review" (rather than "Always Proceed"). You have to read, evaluate, and approve
|
|
|
-the AI's Python and database logic before it is committed, ensuring you actually
|
|
|
-understand the code being generated.
|
|
|
-• You can use the Gemini CLI to quickly test database queries or prompt logic in
|
|
|
-the terminal before having the Antigravity agent implement it into the main
|
|
|
-codebase.
|
|
|
-• All artifacts generated by Antigravity, e.g. task lists, implementation plans and
|
|
|
-browser recordings, must be attached to the corresponding task and/or user
|
|
|
-story in Taiga.
|
|
|
-• In a real-world Agile environment, code commits must be traceable back to the
|
|
|
-business requirements (User Stories). You must instruct your Antigravity
|
|
|
-agent(s): "When you commit this code, use the commit message: 'TG-<Taiga
|
|
|
-task id>: <Taiga task description>' . Do not attempt to push". If the AI reports a
|
|
|
-'sandbox error' or 'permission denied' when trying to push, it is not a
|
|
|
-technical problem - it is a safety feature. Perform the push manually in the
|
|
|
-terminal, then tell the AI to proceed with the next step.
|
|
|
-• Daily Workflow with Antigravity
|
|
|
-You are the Tech Lead; Antigravity is your Development Team. You do not write
|
|
|
-code; you direct the Antigravity agent.
|
|
|
-o Planning (Thursday):
|
|
|
-• Create User Stories with clear story title and acceptance criteria in
|
|
|
-Taiga for your planned work. To do this you can provide Antigravity
|
|
|
-with the project vision statement and let it generate all the scrum
|
|
|
-artifacts for you and it can even feed them directly into Taiga via
|
|
|
-the Taiga API.
|
|
|
-• In Taiga, break the Story into specific tasks for Antigravity and note
|
|
|
-the task ids (e.g. #3).
|
|
|
-o Development (Thursday/Friday):
|
|
|
-• Orchestrate: Feed your Taiga Task to Antigravity’s Agent Manager.
|
|
|
-Here's an example prompt: "Work on Taiga Task #1. Write a Python
|
|
|
-script to initialize the SQLite database. Once complete, stage,
|
|
|
-commit, and push the files with the commit message: 'TG-1:
|
|
|
-Initialize SQLite DB'."
|
|
|
-Pro-Tip: Create a PROJECT_CONTEXT.md file in the root of your
|
|
|
-repository that outlines your tech stack (Ubuntu, Ollama, SearXNG,
|
|
|
-Database, ...) and the strict "No external APIs" rule. Instruct
|
|
|
-Antigravity to "Read PROJECT_CONTEXT.md before starting" so it
|
|
|
-never hallucinates cloud-based solutions.
|
|
|
-• Review: Set Review Policy to "Request Review." Evaluate the AI's
|
|
|
-Python/Database logic before approving. Before approving the
|
|
|
-commit, verify that:
|
|
|
-• The agent included the TG-<ID> prefix in the commit
|
|
|
-message.
|
|
|
-• The code is strictly local (no external API calls).
|
|
|
-• The logic is correct based on your technical research.
|
|
|
-• Attach: Download the AI's Implementation Plan and attach it to the
|
|
|
-Taiga ticket.
|
|
|
-o The Golden Rule of committing:
|
|
|
-Every time you push code, make sure Antigravity has linked it to a Taiga
|
|
|
-Task ID in the commit message so the webhook works. If that's the case,
|
|
|
-you only need to run git push if not:
|
|
|
-git add .
|
|
|
-git commit -m "TG-<ID>: [Your short description]"
|
|
|
-git push
|
|
|
-(Example: git commit -m "TG-1: Setup SQLite DB structure" )
|
|
|
-o Verification
|
|
|
-• Taiga: Open your User Story (e.g., #1) and check the History/Git
|
|
|
-tab. You should see your commit message appear there
|
|
|
-automatically.
|
|
|
-• Gogs: Check your Webhook "Recent Deliveries." You should see
|
|
|
-green checkmarks (204 No Content).
|
|
|
-Troubleshooting:
|
|
|
-• If you do not tell the AI to use the TG-<ID> format in the
|
|
|
-commit message, your Taiga board will not update.
|
|
|
-• If you see "Referenced element doesn't exist," verify your
|
|
|
-commit message has the correct TG-<ID> format matching
|
|
|
-an existing Story ID in Taiga.
|
|
|
-
|