chore: impl app versioning

.changeset/README.md

@@ -0,0 +1,8 @@
+# Changesets
+
+Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
+with multi-package repos, or single-package repos to help you version and publish your code. You can
+find the full documentation for it [in our repository](https://github.com/changesets/changesets)
+
+We have a quick list of common questions to get you started engaging with this project in
+[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md)

.changeset/config.json

@@ -0,0 +1,11 @@
+{
+	"$schema": "https://unpkg.com/@changesets/config@3.1.2/schema.json",
+	"changelog": "@changesets/cli/changelog",
+	"commit": false,
+	"fixed": [],
+	"linked": [],
+	"access": "restricted",
+	"baseBranch": "main",
+	"updateInternalDependencies": "patch",
+	"ignore": []
+}

.github/workflows/version.yml

@@ -0,0 +1,37 @@
+# .github/workflows/version.yml
+name: Version Packages
+
+on:
+  workflow_dispatch:
+
+jobs:
+  version:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0 # Necessary for Changesets
+
+      - name: Setup pnpm
+        uses: pnpm/action-setup@v2
+        with:
+          version: 8
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18
+          cache: 'pnpm'
+
+      - name: Install dependencies
+        run: pnpm install
+
+      - name: Create Release Pull Request
+        uses: changesets/action@v1
+        with:
+          version: pnpm changeset version
+          title: "chore: update versions for next release"
+          commit: "chore: update package versions"
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

docs/coding-guides/semantic-versioning.md

@@ -0,0 +1,120 @@
+# Semantic Versioning (SemVer) Guide for AI
+
+This guide provides a concise, actionable workflow for versioning and releasing packages in this monorepo. It is intended for language models and automated agents.
+
+---
+
+## 1. Core Concepts
+
+- **Versioning**: `MAJOR.MINOR.PATCH`
+  - `MAJOR`: Breaking changes.
+  - `MINOR`: Backward-compatible new features.
+  - `PATCH`: Backward-compatible bug fixes.
+- **Tooling**: We use **Changesets** for versioning and changelog generation.
+
+---
+
+## 2. Branching Strategy
+
+- **`develop`**: Main development branch. All `feature/*` branches merge here.
+- **`main`**: Production-ready code. Merges come from `release/*` or `hotfix/*`.
+- **`feature/*`**: For new features/fixes. Branched from `develop`.
+- **`release/*`**: To prepare a new release. Branched from `develop`.
+- **`hotfix/*`**: For urgent production fixes. Branched from `main`.
+
+---
+
+## 3. Standard Workflow: Feature Release
+
+This is the most common workflow for developers
+
+### Step 1: Create Feature Branch
+
+```bash
+git checkout develop
+git pull origin develop
+git checkout -b feature/your-feature-name
+```
+
+### Step 2: Implement Changes & Add a Changeset
+
+After making code changes, you **must** add a changeset.
+
+```bash
+pnpm changeset add
+```
+
+Follow the prompts:
+1.  Select the package(s) you changed.
+2.  Choose the correct SemVer bump (`Patch`, `Minor`, or `Major`).
+3.  Write a clear summary of the changes for the changelog.
+
+### Step 3: Commit and Push
+
+Commit the changeset file (`.changeset/*.md`) along with your code.
+
+```bash
+git add .
+git commit -m "feat(scope): your descriptive commit message"
+git push origin feature/your-feature-name
+```
+
+### Step 4: Create a Pull Request
+
+Open a Pull Request from your feature branch to `develop`.
+
+---
+
+## 4. Release Manager Workflow: Publishing a New Version
+
+This process is typically handled by a release manager or an automated CI pipeline.
+
+### Step 1: Create Release Branch
+
+Create a `release` branch from `develop`.
+
+```bash
+git checkout develop
+git pull origin develop
+git checkout -b release/vX.Y.Z
+```
+
+### Step 2: Version the Packages
+
+This command consumes all changesets, updates `package.json` versions, and updates `CHANGELOG.md` files.
+
+```bash
+pnpm changeset version
+```
+
+### Step 3: Commit and Push Version Changes
+
+```bash
+git add .
+git commit -m "chore: bump version for release vX.Y.Z"
+git push origin release/vX.Y.Z
+```
+
+### Step 4: Finalize Release
+
+1.  **Merge to `main`**: Merge the `release/vX.Y.Z` branch into `main` via Pull Request.
+2.  **Tag the release**: After merging, tag the `main` branch.
+    ```bash
+    git checkout main
+    git pull origin main
+    git tag -a vX.Y.Z -m "Release vX.Y.Z"
+    git push origin vX.Y.Z
+    ```
+3.  **Merge back to `develop`**: Merge the release branch back into `develop`.
+    ```bash
+    git checkout develop
+    git merge origin/release/vX.Y.Z
+    git push origin develop
+    ```
+
+### Step 5: Publish (CI Action)
+
+A CI job triggered by the new tag will publish the packages.
+
+```bash
+pnpm publish -r --no-git-checks

docs/versioning-and-release-guide.md

@@ -0,0 +1,135 @@
+#  Versioning and Releases
+
+This document provides a complete guide to the versioning and release strategy for this monorepo. It is designed to be clear and concise, enabling any team member to understand and execute the release process.
+
+---
+
+## Part 1: The Core Concepts
+
+### Why do we need this process?
+
+1.  **To Stop "It works on my machine"**: By standardizing versions, we ensure that every developer is using the exact same code, which prevents bugs caused by dependency mismatches.
+2.  **To Know What Changed**: Our `CHANGELOG.md` files will be automatically generated from our work. This means we can always see what new features, bug fixes, and breaking changes are in each new version.
+3.  **To Release with Confidence**: This process is predictable and repeatable. It removes guesswork and makes creating new version tags a safe, routine task instead of a stressful event.
+
+### What is Semantic Versioning (SemVer)?
+
+It's a simple promise about what a version number means. Given a version `MAJOR.MINOR.PATCH`:
+- **`MAJOR`**: Is for **breaking changes**. If we change this, other developers know they might need to change their code to adapt.
+- **`MINOR`**: Is for **new features** that are backward-compatible. We've added something new, but nothing should break.
+- **`PATCH`**: Is for **bug fixes** that are backward-compatible. We've fixed something that was broken, but nothing new has been added.
+
+### What is "Changesets"?
+
+Changesets is the tool that powers our workflow. It's a small command-line assistant that does two things:
+1.  **Asks you to describe your changes**: When you've finished your work, you tell Changesets what you did. It saves this as a small file.
+2.  **Turns those descriptions into a release**: When we're ready to release, it gathers up all those small files, updates the version numbers in `package.json`, and rebuilds the `CHANGELOG.md` files for us.
+
+---
+
+## Part 2: The Daily Workflow (For Every Developer)
+
+This is the process every developer must follow for **every feature, bug fix, or chore**.
+
+### Step 1: Create Your Branch
+
+Always start by creating a branch from the `develop` branch.
+
+```bash
+# Make sure you have the latest code
+git checkout develop
+git pull origin develop
+
+# Create your new branch
+git checkout -b feature/my-new-feature
+```
+
+### Step 2: Do Your Work
+
+Make all your code changes as you normally would.
+
+### Step 3: Add a "Changeset" (Crucial Step!)
+
+This is the most important new step. When you have finished your work and are ready to commit, you must tell the Changesets tool what you did.
+
+1.  **Run the command:**
+    ```bash
+    pnpm changeset add
+    ```
+
+2.  **The tool will ask you questions:**
+    -   **"Which packages did you change?"**: Use the arrow keys and spacebar to select all the apps or packages you worked on.
+    -   **"Which packages should have a `major` bump?"**: You will almost **never** choose `major`. Only do this if you have made a breaking change.
+    -   **"Which packages should have a `minor` bump?"**: Choose this if you added a **new feature**.
+    -   **"Which packages should have a `patch` bump?"**: Choose this if you made a **bug fix**.
+    -   **"What is a summary of your changes?"**: Write a clear, concise message that will appear in the changelog. This should be written for other developers to read.
+        -   **Good Example:** `feat: Add user profile page with avatar upload.`
+        -   **Bad Example:** `made some changes`
+
+3.  **A new file is created**: The tool will generate a new markdown file in the `.changeset` directory. This file contains the information you just provided.
+
+### Step 4: Commit and Push
+
+Now, commit both your code changes and the new changeset file.
+
+```bash
+git add .
+git commit -m "feat: your commit message here"
+git push origin feature/my-new-feature
+```
+
+### Step 5: Create a Pull Request
+
+Create a Pull Request from your feature branch to the `develop` branch. That's it! Your part is done. The changelog entry for your work is now "banked" and ready for the next release.
+
+---
+
+## Part 3: The Release Workflow (For the Release Manager)
+
+This process is performed only when we are ready to create a new release. It should be done by a designated release manager.
+
+### Step 1: Create a Release PR with the "Version Packages" Action
+
+This action will gather all the changeset files that have been merged into `develop` and create a new Pull Request with the version bumps and updated changelogs.
+
+1.  **Go to the "Actions" tab** in the GitHub repository.
+2.  **Select the "Version Packages" workflow** from the list on the left.
+3.  **Click the "Run workflow" button.** A dropdown will appear.
+4.  **Keep the branch as `develop`** and click the green "Run workflow" button.
+
+The action will now run. When it's finished, a new Pull Request will be automatically created. The title will be something like `"chore: update versions for next release"`.
+
+### Step 2: Review and Merge the Release PR
+
+1.  **Open the new Pull Request.**
+2.  **Review the changes.** Check the `CHANGELOG.md` files to ensure they look correct.
+3.  **Merge the Pull Request** into the `develop` branch.
+
+### Step 3: Create and Push the Git Tag
+
+Once the release PR is merged, you need to create a Git tag for the new version. This tag serves as a permanent, browsable marker for the release.
+
+1.  **Find the version number**: Look at the `package.json` of one of the apps in the `develop` branch to see what the new version number is (e.g., `1.2.0`).
+2.  **Create the tag on your local machine**:
+    ```bash
+    # Make sure you are on the develop branch with the latest changes
+    git checkout develop
+    git pull origin develop
+
+    # Create an annotated tag (the -a flag is important)
+    git tag -a v1.2.0 -m "Release version 1.2.0"
+    ```
+3.  **Push the tag to GitHub**:
+    ```bash
+    git push origin v1.2.0
+    ```
+
+### Step 4: Merge to `main` to Finalize the Release
+
+The final step is to merge the release into the `main` branch to keep it up-to-date with the latest stable code.
+
+1.  Create a Pull Request from `develop` to `main`.
+2.  Title it `Release v1.2.0`.
+3.  Review and merge the Pull Request.
+
+The release is now complete! The new tag is available in GitHub, the changelogs are updated, and the `main` branch is synced with the latest release.

frontend/account-manager-app/.env

@@ -1,10 +1,10 @@
-VITE_FINERACT_API_URL=/fineract-provider/api
+VITE_FINERACT_API_URL=https://localhost/fineract-provider/api
 VITE_FINERACT_TENANT_ID=default
 
 # Authentication Mode: 'oauth' (recommended) or 'basic' (development only)
-VITE_AUTH_MODE=oauth
+VITE_AUTH_MODE=basic
 
 # Basic Auth credentials (only used when VITE_AUTH_MODE=basic)
 # DO NOT commit real credentials - use .env.local for local overrides
-VITE_FINERACT_USERNAME=
-VITE_FINERACT_PASSWORD=
+VITE_FINERACT_USERNAME=mifos
+VITE_FINERACT_PASSWORD=password

frontend/account-manager-app/src/pages/dashboard/Dashboard.view.tsx

@@ -27,14 +27,14 @@ export const DashboardView: FC<ReturnType<typeof useDashboard>> = ({
 			<main className="p-4 sm:p-6 lg:p-8">
 				<div className="flex flex-col md:flex-row justify-between items-center mb-8">
 					<h1 className="text-4xl font-bold text-gray-800 mb-4 md:mb-0">
-						{t("dashboard.clients")}
+						{t("dashboard.title")}
 					</h1>
 					<div className="flex items-center space-x-4 w-full md:w-auto">
 						<SearchBar
 							value={searchValue}
 							onValueChange={onSearchValueChange}
 							onSearch={onSearch}
-							placeholder={t("dashboard.searchClientsByName")}
+							placeholder={t("dashboard.searchPlaceholder")}
 							className="w-full md:w-64"
 						/>
 						<Link to="/create-client">
@@ -47,7 +47,7 @@ export const DashboardView: FC<ReturnType<typeof useDashboard>> = ({
 				</div>
 
 				{isFetchingClients ? (
-					<p>{t("dashboard.loadingClients")}</p>
+					<p>{t("dashboard.loading")}</p>
 				) : (
 					<>
 						<div className="md:hidden">
@@ -69,7 +69,7 @@ export const DashboardView: FC<ReturnType<typeof useDashboard>> = ({
 															{client.displayName}
 														</h2>
 														<p className="text-sm text-gray-500">
-															{t("dashboard.accountNo")}: {client.accountNo}
+															{t("dashboard.accountNumber")}: {client.accountNo}
 														</p>
 													</div>
 													<span

frontend/account-manager-app/src/routes/__root.tsx

@@ -1,6 +1,7 @@
 import {
 	AppLayout,
 	Button,
+	Footer,
 	menuAccountManager,
 	Navbar,
 	Sidebar,
@@ -69,6 +70,7 @@ function RootLayout() {
 				<Outlet />
 				<TanStackRouterDevtools />
 			</AppLayout>
+			<Footer />
 		</>
 	);
 }