ADRs: Filling in impact sections for 001 - 006

.github/workflows/pr_agent.yml

@@ -0,0 +1,32 @@
+name: Perry the PR Agent Platypus
+
+# Config for this action lives in .pr_agent.toml, but only the version on
+# main is read - you'll need to merge config changes before they take effect.
+# You can test config changes by making them in the `env` section below, but
+# should then move them to the config file for consistency/readability
+
+on:
+  pull_request:
+  issue_comment:
+    types: [created]
+jobs:
+  pr_agent_job:
+    if: ${{ github.event.sender.type != 'Bot' }}
+    runs-on: ubuntu-latest
+    permissions:
+      issues: write
+      pull-requests: write
+      contents: write
+    name: Run pr agent on every pull request, respond to user comments
+    steps:
+      - name: PR Agent action step
+        id: pragent
+        uses: Codium-ai/pr-agent@main
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          OPENAI_KEY: ${{ secrets.AZURE_OPENAI_KEY }}
+          OPENAI.API_TYPE: 'azure'
+          OPENAI.API_BASE: ${{ secrets.AZURE_OPENAI_BASE_URL }}
+          OPENAI.DEPLOYMENT_ID: ${{ secrets.AZURE_OPENAI_DEPLOYMENT_ID }}
+          OPENAI_API_VERSION: '2023-03-15'
+          AZURE_API_VERSION: '2023-03-15-preview' # Specific version required to address compatibility issues with GPT-4 deployment on Azure.

.pr_agent.toml

@@ -0,0 +1,45 @@
+# See https://github.com/Codium-ai/pr-agent/blob/main/pr_agent/settings/configuration.toml for all possible config options
+# The pr_agent.yml action reads this file from the `main` branch, so changes to this file
+# will not take effect until they are merged into main
+
+[config]
+model="gpt-4" # the OpenAI model you've deployed on Azure (e.g. gpt-3.5-turbo)
+model_turbo="gpt-4" # the OpenAI model you've deployed on Azure (e.g. gpt-3.5-turbo)
+fallback_models=["gpt-4"] # the OpenAI model you've deployed on Azure (e.g. gpt-3.5-turbo)
+
+[github_action_config]
+auto_review = true
+auto_describe = false
+auto_improve = true
+pr_actions = ["opened", "reopened", "ready_for_review", "review_requested"]
+
+[pr_reviewer] # /review #
+# enable/disable features
+# general options
+num_code_suggestions=3 # Number of code suggestions provided by the 'review' tool. Default is 0, meaning no code suggestions will be provided by the `review` tool.
+inline_code_comments = true # If set to true, the tool will publish the code suggestions as comments on the code diff. Default is false. Note that you need to set `num_code_suggestions`>0 to get code suggestions
+ask_and_reflect=false
+persistent_comment=false
+#automatic_review=true
+extra_instructions = "" # Optional extra instructions to the tool. For example: "focus on the changes in the file X. Ignore change in ...".
+final_update_message = true # If set to true, it will add a comment message [`PR Description updated to latest commit...`](https://github.com/Codium-ai/pr-agent/pull/499#issuecomment-1837412176) after finishing calling `/describe`. Default is false.
+# review labels
+enable_review_labels_security=false # If set to true, the tool will publish a 'possible security issue' label if it detects a security issue. Default is true.
+enable_review_labels_effort=false # If set to true, the tool will publish a 'Review effort [1-5]: x' label. Default is true.
+# specific configurations for incremental review (/review -i)
+require_all_thresholds_for_incremental_review=false
+minimal_commits_for_incremental_review=0
+minimal_minutes_for_incremental_review=0
+enable_intro_text=true
+enable_help_text=false # Determines whether to include help text in the PR review. Enabled by default.
+# auto approval
+enable_auto_approval=false # If set to true, the tool will approve the PR when invoked with the 'auto_approve' command. Default is false. This flag can be changed only from a configuration file.
+
+[pr_description] # /describe #
+publish_labels=false
+# describe as comment
+publish_description_as_comment=true
+publish_description_as_comment_persistent=false
+
+[pr_code_suggestions] # /improve #
+persistent_comment=false

adr/001-architecture-decision-records.md

@@ -17,30 +17,45 @@ ADRs are originally described by [Michael Nygard in an article](https://cognitec
 We want to record our architectural decisions so that...
 
 - New team members who join can see why we made the decisions we made.
+
+
 - The team can revise or revisit decisions with more confidence and context.
 
 ## Impact
 
-_The outcomes of the decision, both positive and negative. This section explains the impact of the decision, such as trade-offs, risks, and what needs to be done to implement it._
+The outcomes of the decision, both positive and negative. This section should explain the impact of the decision, such as trade-offs, risks, and what needs to be done to implement it.
 
 ### Positive
 
 - **Transparency**: ADRs make decision-making more transparent, helping current and future team members understand the rationale behind decisions.
+
+
 - **Historical Context**: They provide valuable historical context, aiding in future decision-making and avoiding repeated mistakes.
+
+
 - **Onboarding**: ADRs speed up the onboarding process by quickly familiarizing new team members with architectural decisions.
+
+
 - **Consistency**: A standardized format ensures consistent documentation, making records easier to maintain and reference.
 
 ### Negative
 
 - **Overhead**: Maintaining ADRs requires time and effort.
+
+
 - **Outdated Records**: If not regularly updated, ADRs can become outdated and misleading.
 
 ### Risks
 
 - **Incomplete Documentation**: Not all decisions may be documented, leading to gaps in the record.
+
+
 - **Misalignment**: ADRs may not always match the actual implementation, causing confusion.
 
 ## Related Issues
 
 - #1
 - #13
+- #1247
+
+### Please see [adr-guidelines.md](adr/adr-guidelines.md) before completing.

adr/002-java.md

@@ -4,7 +4,8 @@ Date: 2022-10-21
 
 ## Decision
 
-We will use Java 17 for the main trusted intermediary code.
+We will use Java 17 for the main intermediary code.
+
 This doesn't preclude us from using other languages for other services or applications.
 
 ## Status
@@ -13,10 +14,31 @@ Accepted.
 
 ## Context
 
-We decided to use a JVM based language because it has many third-party healthcare libraries and frameworks.
+We decided to use a Java Virtual Machine- (JVM) based language because it has many third-party healthcare libraries and frameworks that are pertinent to the project. 
 
 We decided on Java over Kotlin, Scala, and Groovy because more people know Java.
 
+## Impact
+
+### Positive
+
+- **Robust and Well-Maintained Libraries:** has robust libraries, like HAPI FHIR, which provide comprehensive support for creating, parsing, and validating FHIR resources. Libraries are well-maintained and widely used in the healthcare industry
+
+
+- **Powerful Data Processing:** ability to handle large-scale, multithreaded applications makes it suitable for processing large volumes of FHIR data in real-time, which is crucial in healthcare settings
+
+
+- **Compliant Security Features:** Java's security features, such as encryption and secure authentication mechanisms, help in building HIPAA-compliant FHIR applications.
+
+### Negative
+
+- **Verbose Code:** Code tends to be more verbose leading to longer development times and more boilerplate code.
+
+
+### Risks
+
+- **Limited Functional Expression:** Limited functional programming capabilities can make it harder to express certain data transformation logic that is common in FHIR processing, compared to languages with stronger functional programming support.
+
 ### Related Issues
 
 - #1

adr/003-gradle.md

@@ -4,21 +4,51 @@ Date: 2022-10-24
 
 ## Decision
 
-We will use the [Gradle build tool](https://gradle.org) for the main trusted intermediary code.
+We will use the [Gradle build tool](https://gradle.org) for the main intermediary code.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-[Maven](https://maven.apache.org) is the other big option available to us.  Gradle was chosen over Maven because
-- it uses Groovy, an actual programming language, to configure the projects instead of XML, which has a rigidly defined schema.
-  This allows for better expressibility in how one configures their project.
+Other build tools were considered; [Maven](https://maven.apache.org) is the other big option available to us.  Gradle was chosen over Maven because
+- Gradle uses Groovy, an actual programming language, to configure the projects instead of XML (Extensible Markup Language), which has a rigidly defined schema.
+
+
+- Gradle allows for diversity in configuration of the project.
+
+
 - Gradle is faster with its job execution.
 
 
-### Related Issues
+## Impact
+
+### Positive
+
+- **Advanced Dependency Management** capabilities help streamline the integration of FHIR libraries, such as HAPI FHIR, and other required dependencies
+
+
+- **Highly Customizable Scripts:** Highly customizable build scripts allow for fine-tuned configuration.
+
+
+- **Reduced build times**
+
+
+- **CI/CD Automation:** integrates well with continuous integration and continuous deployment (CI/CD) pipelines, enabling automated testing
+
+### Negative
+
+- **Cumbersome Build Scripts:** Flexibility can lead to complex and verbose build scripts; Managing these scripts can become cumbersome.
+
+
+- **Configuration Incompatibility:** Custom configurations may not be fully compatible with certain versions of Java or FHIR libraries.
+
+### Risks
+
+- **Possible Slow Build Times** due to scripts and project size
+
+## Related Issues
 
 - #1
 - #13

adr/004-groovy-spock.md

@@ -4,24 +4,51 @@ Date: 2022-10-24
 
 ## Decision
 
-We will use the [Groovy programming language](http://groovy-lang.org) with the
-[Spock testing framework](https://spockframework.org) for our unit and end-to-end testing.
+We will use the [Groovy programming language](http://groovy-lang.org) with the [Spock testing framework](https://spockframework.org) for our unit and end-to-end testing.
 
 ## Status
 
 Accepted.
 
 ## Context
 
-Spock is a testing framework similar to [JUnit](https://junit.org/junit5/).  Some benefits of Spock include...
+Spock is a testing framework similar to [JUnit](https://junit.org/junit5/).  Some benefits of Spock include: 
+
 - Encourages BDD-style given/when/then testing.
+
 - Mocking is _super_ easy.  No need for a separate dependency like [Mockito](https://site.mockito.org).
+
 - Expressive assertion failures.  No need for a separate dependency like [Google Truth](https://truth.dev).
+
 - Adds a layer of flexibility and expressiveness to testing that you don't get with JUnit.
 
 Spock requires we use Groovy, another JVM-based language.
 
-### Related Issues
+## Impact
+
+### Positive
+
+- **Expressive and readable tests**
+
+
+- **Data-driven Testing:** supports data-driven testing which is useful for testing FHIR resources across a variety of scenarios with different data sets
+
+
+- **Integrates well with Java**
+
+### Negative
+
+- **Limited IDE Support:** writing and debugging tests can become cumbersome 
+
+### Risks
+
+- **Slower Test Execution:** Tests can potentially run slower compared to simpler JUnit tests, especially for larger test suites. 
+
+
+- **Dependency Management:** Managing Groovy dependencies alongside Java libraries may introduce complexity or compatibility issues in certain build environments.
+
+
+## Related Issues
 
 - #1
 - #13

adr/005-oea.md

@@ -0,0 +1,60 @@
+# 5. Option Enabling Architecture (OEA)
+
+Date: 2022-10-24
+
+## Decision
+
+We will use use OEA practices to inform how we add new features and refactor.
+
+## Status
+
+Accepted.
+
+## Context
+
+OEA is similar to [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html).
+There are a couple main concepts that we strive to maintain while also being pragmatic.
+
+1. Less important code depends on more important code.  For example, third-party dependencies such as ReST
+   frameworks, and database ORMs.  This allows for swapping out less important code without affecting the more
+   important code.
+
+
+2. Dependency inversion.  This allows the path of code execution not to follow the dependency path of
+   less important code depending on more important code.  For example, when business logic needs to call the
+   database.
+
+## Impact
+
+### Positive
+
+- **More flexible architecture**
+
+
+- **Risk mitigation** through delayed decision-making.
+
+
+- **Minimizes large-scale changes and overhauls**
+
+
+- **Better maintainability**
+
+### Negative
+
+- **Experience May Be Required:** requires more experience to implement successfully
+
+
+- **Increased initial development time**
+
+
+- **Increased Planning:** requires much more forethought prior to implementation
+
+### Risks
+
+- **Overengineering:** potential to overengineer by keeping too many options open
+- Deferred decision-making can lead to technical debt
+
+## Related Issues
+
+- #1
+- #13