docs(spec): encourage kagi web search during planning

Have the Design sub-agent use the kagi command to research documented
library, API, and platform behavior rather than guessing, and document
the kagi command itself in a new Notes section.

Co-authored-by: GLM-5.3 <noreply@z.ai>

Author: sampottinger

kigali_ai_spec.md

@@ -274,7 +274,7 @@ This prototype is to be built through a multi-agent flow.
 ### Proceedure
 An agent (coordinating agent) will be assigned a component and it will do the following:
 
- - **Design**: Use a sub-agent to look at existing code and design a full solution. This agent should not yet modify live code but further clarify the implementation plan, highlighting questions for the user as needed. That plan should be written into this file in the subsection corresponding to the component assigned. It should only work on the component assigned. Please also have this sub-agent check if some of the work that needs to be done is better in or mentioned as assigned to later components and indicate that work as out of scope. Check git diff before concluding.
+ - **Design**: Use a sub-agent to look at existing code and design a full solution. This agent should not yet modify live code but further clarify the implementation plan, highlighting questions for the user as needed. That plan should be written into this file in the subsection corresponding to the component assigned. It should only work on the component assigned. Please also have this sub-agent check if some of the work that needs to be done is better in or mentioned as assigned to later components and indicate that work as out of scope. Where a design question hinges on documented behavior of a library, API, or platform (for example TeaVM / WASM constraints or a provider request format), have this sub-agent use the `kagi` command for web search to learn more about the problem and confirm assumptions rather than guess (see Notes at the bottom of this file). Check git diff before concluding.
  - **Implement**: Use a sub-agent to implement the component, completing only the component assigned. A description of what was done should be written into this file. This sub-agent should work to implement successfully and pass relevant checks given the sope of the change (ex: `./gradlew test`) after adding relevant unit tests but not worry about stylechecks like `./gradlew checkstyleMain checkstyleTest`. If anything unexpected emerged that could not be resolved, it should let the coordinating agent know so they can raise it to the user. It should only work on the component assigned. Check git diff before concluding.
  - **Clean**: Use a sub-agent to check the implementation of the component and improve it where appropriate before ensuring style issues are resolved and checking that `./gradlew checkstyleMain checkstyleTest` (or similar depending on scope) passes. If anything unexpected emerged that could not be resolved, it should let the coordinating agent know so they can raise it to the user. This sub-agent should look for similar pre-existing code in the project and ensure new code follows similar conventions. It should only work on the component assigned. Check git diff before starting and before concluding.
  - **Finalize**: If there are no open questions for the user, use a sub-agent to double check all automated checks relevant to the change pass including `./gradlew test checkstyleMain checkstyleTest`. It should confirm these first. Next, if and only if the component was implemented successfully, this sub-agent should summarize the whole component just completed in no more than 4-5 sentences and replace that component's design plan and implementation notes in this file with that summary, so that this specification does not grow too long; if the component was not completed successfully, it should leave the plan and details in place so any open work remains visible. Afterwards, it should check if the system context file needs any updates given the changes made in this component (remembering that the LLM will not be able to access the internet). Finally, it should commit. In that commit, `A Samuel Pottinger <sam.pottinger@berkeley.edu>` should be author but the following co-author tag is expected: `Co-authored-by: DeepSeek V4.1 Flash (via OpenRouter) <noreply@deepseek.com>`. It should only work on the component assigned. Check git diff before starting and before concluding.
@@ -376,3 +376,8 @@ We should add support for `.md` files in the workspaces for both JVM and WASM wh
 #### Component 22: Privacy policy
 The privacy policy should be updated to indicate that cookies are used but essential only to keep track of which simluation is open. This is not transmitted back for analytics. We should also add that supporting data files and chats are also held locally. Finally, in the chat list, we should mention that chats are saved locally on the user’s machine only. Then, we should do something similar in the supporting files and simulation files list.
 
+<br>
+
+## Notes
+To web search, please use the Kagi command like so: `kagi search --format pretty "test"`.
+