[DOCS] FINAL ADJUSTMENTS

docs/Design/SoftDetailedDes/MIS.tex

@@ -2169,12 +2169,13 @@ \subsection{Syntax}
   \textbf{Name} & \textbf{In} & \textbf{Out} & \textbf{Exception} \\
   \hline
   \texttt{setCachedSmells} & \texttt{filePath: string, smells: Smell[]} & Promise$<$void$>$ & None \\ \hline
-  \texttt{getCachedSmells} & \texttt{filePath: string} & Smell[] \| \text{undefined} & None \\ \hline
+  \texttt{getCachedSmells} & \texttt{filePath: string} & Smell[] or \ \text{undefined} & None \\ \hline
   \texttt{hasCachedSmells} & \texttt{filePath: string} & boolean & None \\ \hline
   \texttt{clearAllCachedSmells} & None & Promise$<$void$>$ & None \\
   \hline
 \end{tabularx}
 
+
 \subsection{Semantics}
 
 \subsubsection{State Variables}

docs/HazardAnalysis/HazardAnalysis.tex

@@ -410,7 +410,7 @@ \section{Critical Assumptions}
     \end{itemize} & 
     \begin{itemize}[wide=0pt]
         \item Add progress bars and time estimates for long operations.
-        \item Provide status updates (e.g., "Measuring energy... 75\%").
+        \item Provide status updates (e.g., ``Measuring energy... 75\%'').
     \end{itemize} & SCR-13 & HZ-\showmycounter \\ \cline{2-7}
 
     & Inaccessible UI for users with disabilities & 
@@ -672,15 +672,15 @@ \subsubsection*{Mya Hussain}
   Determining which factors qualify as hazards for our analysis was somewhat unclear.
   A hazard is defined as anything with the potential to cause harm or loss, yet certain    
   risks may emerge from poor design, complicating our decision on whether to include them.    
-  For example, user interface hazards like "the tool does not provide clear feedback    
-  to the user after refactoring" can technically be classified as a hazard. While we    
+  For example, user interface hazards like ``the tool does not provide clear feedback    
+  to the user after refactoring'' can technically be classified as a hazard. While we    
   aim to mitigate team-imposed hazards, it raises the question of whether we should    
   simply avoid designing a flawed product in the first place, and not include these    
   hazards in the analysis or if we should do a worst-case analysis and include every    
   possible pitfall. The same argument could be made for some security hazards for example    
-  "while parsing user input code, the software encounters malware and executes it,"    
+  ``while parsing user input code, the software encounters malware and executes it,''    
   avoiding this is something a good tool should already have built in, so it begs    
-  the question of "how bad do we envision our final product when analyzing hazards?"    
+  the question of ``how bad do we envision our final product when analyzing hazards?''    
   We were able to get some clarification on this in our TA 1-1 meeting but ultimately    
   tried to keep it high level so our report didn't end up being too long.
 

docs/ProblemStatementAndGoals/ProblemStatement.tex

@@ -37,6 +37,7 @@
     March 24th, 2025 & Mya Hussain & Removed mentions of database storing \\
     March 24th, 2025 & Ayushi Amin & Fixed formatting and grammar/spelling \\
     March 24th, 2025 & Sevhena Walker & Update the aspects of the plugin \\
+    April 4th, 2025 & Ayushi Amin & Removed reinforcement learning from current plan \\
     \bottomrule
   \end{tabularx}
 \end{table}
@@ -93,8 +94,6 @@ \subsubsection*{\color{blue}{Indirect Stakeholders}}
 \end{enumerate}
 
 \subsection{Environment}
-\textbf{Reinforcement Learning Library:} \textit{Stable Baselines}
-will be the library to implement reinforcement learning techniques.\\
 \textbf{Development Frameworks and Tools:}
 \begin{enumerate}
 

docs/SRS/SRS.tex

@@ -1298,13 +1298,6 @@ \subsection{Learning Requirements}
     {\bf Fit Criterion:} Help resources should be accessible within
     MAX\_TASK\_CLICKS limit.\\
     {\bf Priority:} High
-  \item \emph{The tool shall have an available YouTube video
-    demonstrating installation.}\\[2mm]
-    {\bf Rationale:} Video tutorials provide visual learning
-    resources that can make the installation process more accessible to users.\\
-    {\bf Fit Criterion:} A YouTube video demonstrating installation
-    should be present and easily accessible.\\
-    {\bf Priority:} Low
 \end{enumerate}
 
 \subsection{Understandability and Politeness Requirements}

docs/VnVReport/VnVReport.tex

@@ -3121,7 +3121,7 @@ \subsection{Usability and User Input Adjustments}
 usability testing, it became evident that an \textbf{option to
 refactor all occurrences of the same smell type} would significantly
 improve efficiency. This led to the introduction of a
-\textbf{"Refactor Smell of Same Type"} feature in the VS Code
+\textbf{``Refactor Smell of Same Type''} feature in the VS Code
 extension, allowing users to apply the same refactoring across
 multiple instances of a detected smell simultaneously. Additionally,
 we refined the \textbf{Accept/Reject UI elements} to make them more