nitor 1.6.0 → 1.7.0

package/docs/CREATE_BRANCH.md

@@ -1,173 +0,0 @@
-# Create Branch Command Guide
-
-## Overview
-
-The `create-branch` command creates a new Git branch following a standardized naming convention based on task number, type, and description.
-
-## Usage
-
-### Basic Syntax
-
-```bash
-nitor create-branch -task <task number> -type <feat|fix> -description <description> -project <project short name>
-```
-
-### Short Form
-
-```bash
-nitor create-branch -t <task number> -ty <feat|fix> -d <description> -p <project short name>
-```
-
-## Options
-
-| Option          | Short   | Description        | Values                                                                                                                                        |
-| --------------- | ------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `--task`        | `-t`    | Task number        | Any task/ticket number                                                                                                                        |
-| `--type`        | `-ty`   | Branch type        | `feat`, `fix`                                                                                                                                 |
-| `--description` | `-d`    | Branch description | Any descriptive text                                                                                                                          |
-| `--project`     | `-p`    | Project short name | `portal`, `gateway`, `phr`, `configService`, `healthRecords`, `centralAuth`, `mpi`, `phrAdminBackend`, `phrAdminClient`, `terminologyService` |
-| `--help`        | `-help` | Show help          | -                                                                                                                                             |
-
-## Examples
-
-### Create Feature Branch
-
-```bash
-nitor create-branch -t 1234 -ty feat -d "add-user-authentication" -p portal
-```
-
-This creates a branch like: `feat/1234-add-user-authentication`
-
-### Create Bug Fix Branch
-
-```bash
-nitor create-branch -task 5678 -type fix -description "fix-login-issue" -project gateway
-```
-
-This creates a branch like: `fix/5678-fix-login-issue`
-
-### Create Branch Without Project
-
-```bash
-nitor create-branch -t 9012 -ty feat -d "update-api-endpoints"
-```
-
-## Branch Types
-
-### feat (Feature)
-
-Use for new features or enhancements:
-
-- New functionality
-- Feature additions
-- Enhancements to existing features
-
-### fix (Bug Fix)
-
-Use for bug fixes:
-
-- Bug corrections
-- Issue resolutions
-- Hotfixes
-
-## Branch Naming Convention
-
-Branches are created following this pattern:
-
-```
-<type>/<task-number>-<description>
-```
-
-**Examples:**
-
-- `feat/1234-user-profile-page`
-- `fix/5678-login-validation-error`
-- `feat/9012-api-integration`
-
-## Supported Projects
-
-- **portal** - Portal application
-- **gateway** - Gateway service
-- **phr** - Personal Health Records
-- **configService** - Configuration service
-- **healthRecords** - Health records service
-- **centralAuth** - Central authentication service
-- **mpi** - Master Patient Index
-- **phrAdminBackend** - PHR admin backend
-- **phrAdminClient** - PHR admin client
-- **terminologyService** - Terminology service
-
-## Branch Creation Process
-
-The command will:
-
-1. Validate task number, type, and description
-2. Format the branch name according to convention
-3. Create the new branch from current branch
-4. Checkout to the new branch
-
-## Best Practices
-
-### Description Guidelines
-
-- Use lowercase letters
-- Use hyphens to separate words
-- Be descriptive but concise
-- Avoid special characters
-
-**Good:**
-
-- `add-user-authentication`
-- `fix-payment-gateway-error`
-- `update-dashboard-layout`
-
-**Avoid:**
-
-- `Add User Authentication` (uppercase)
-- `fix_payment_error` (underscores)
-- `update` (too vague)
-
-### Task Numbers
-
-- Use your project management system's task/ticket number
-- Ensure the number is accurate for tracking
-- Include the full ticket number
-
-## Troubleshooting
-
-### Branch Already Exists
-
-If the branch name already exists:
-
-1. Check if you're working on the same task
-2. Use a different description
-3. Delete the old branch if it's no longer needed
-
-### Invalid Branch Type
-
-Ensure you're using one of the supported types:
-
-- `feat` for features
-- `fix` for bug fixes
-
-### Git Errors
-
-If you encounter Git errors:
-
-1. Ensure you're in a Git repository
-2. Check that you have uncommitted changes
-3. Verify Git is properly configured
-
-## Getting Help
-
-To see all available options:
-
-```bash
-nitor create-branch -help
-```
-
-## Related Commands
-
-- `nitor merge` - Merge branches
-- `nitor cleanup` - Clean up local branches
-- `nitor review` - Review merge requests

package/docs/DEPLOY.md

@@ -1,130 +0,0 @@
-# Deploy Command Guide
-
-## Overview
-
-The `deploy` command deploys previously built components to specified instances. It works with projects that have already been successfully built.
-
-## Usage
-
-### Basic Syntax
-
-```bash
-nitor deploy -project <project name> -components <component name> -instance <instance name>
-```
-
-### Short Form
-
-```bash
-nitor deploy -p <project name> -c <component name> -i <instance name>
-```
-
-## Options
-
-| Option         | Short   | Description    | Values                                                                                                                                        |
-| -------------- | ------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| `--project`    | `-p`    | Project name   | `portal`, `gateway`, `phr`, `configService`, `healthRecords`, `centralAuth`, `mpi`, `phrAdminBackend`, `phrAdminClient`, `terminologyService` |
-| `--components` | `-c`    | Component name | `client`, `administration`, `provider`, `rest-api`                                                                                            |
-| `--instance`   | `-i`    | Instance name  | `dev`, `qa`, `pilot`                                                                                                                          |
-| `--help`       | `-help` | Show help      | -                                                                                                                                             |
-
-## Examples
-
-### Deploy Portal Client to Dev
-
-```bash
-nitor deploy -p portal -c client -i dev
-```
-
-### Deploy Gateway Backend to QA
-
-```bash
-nitor deploy -project gateway -components rest-api -instance qa
-```
-
-### Deploy Multiple Components
-
-```bash
-nitor deploy -p phr -c "client administration" -i pilot
-```
-
-## Supported Projects
-
-- **portal** - Portal application
-- **gateway** - Gateway service
-- **phr** - Personal Health Records
-- **configService** - Configuration service
-- **healthRecords** - Health records service
-- **centralAuth** - Central authentication service
-- **mpi** - Master Patient Index
-- **phrAdminBackend** - PHR admin backend
-- **phrAdminClient** - PHR admin client
-- **terminologyService** - Terminology service
-
-## Supported Components
-
-- **client** - Frontend client application
-- **administration** - Administration panel
-- **provider** - Provider interface
-- **rest-api** - REST API backend
-
-## Supported Instances
-
-- **dev** - Development environment
-- **qa** - Quality assurance environment
-- **pilot** - Pilot/staging environment
-
-## Deployment Process
-
-The deploy command will:
-
-1. Validate project, component, and instance parameters
-2. Check if components are built and ready
-3. Deploy components to the specified instance
-4. Verify deployment status
-5. Report deployment results
-
-## Prerequisites
-
-Before deploying:
-
-- Components must be successfully built
-- You must have proper deployment credentials
-- Target instance must be accessible
-
-## Troubleshooting
-
-### Deployment Fails
-
-1. **Check if build exists:**
-   Ensure components are built before deploying
-
-   ```bash
-   nitor build -p <project> -c <component> -i <instance>
-   ```
-
-2. **Verify credentials:**
-   Check that you have proper deployment permissions
-
-3. **Check instance status:**
-   Ensure the target instance is running and accessible
-
-### Connection Issues
-
-If deployment fails due to connection:
-
-- Verify network connectivity
-- Check VPN connection if required
-- Confirm instance URL is correct
-
-## Getting Help
-
-To see all available options:
-
-```bash
-nitor deploy -help
-```
-
-## Related Commands
-
-- `nitor build` - Build components before deployment
-- `nitor build-deploy` - Build and deploy in one command

package/docs/MERGE.md

@@ -1,253 +0,0 @@
-# Merge Command Guide
-
-## Overview
-
-The `merge` command safely merges a source branch into a target branch with automatic pull and push operations.
-
-## Usage
-
-### Basic Syntax
-
-```bash
-nitor merge -source <source branch> -target <target branch>
-```
-
-### Short Form
-
-```bash
-nitor merge -s <source branch> -ta <target branch>
-```
-
-## Options
-
-| Option     | Short   | Description        | Required |
-| ---------- | ------- | ------------------ | -------- |
-| `--source` | `-s`    | Source branch name | Yes      |
-| `--target` | `-ta`   | Target branch name | Yes      |
-| `--help`   | `-help` | Show help          | -        |
-
-## Examples
-
-### Merge Feature to Development
-
-```bash
-nitor merge -s feat/123-new-feature -ta development
-```
-
-### Merge Development to Master
-
-```bash
-nitor merge -source development -target master
-```
-
-### Merge Fix to Release Branch
-
-```bash
-nitor merge -s fix/456-bug-fix -ta release/v1.2.0
-```
-
-## Merge Process
-
-The merge command performs these steps automatically:
-
-1. **Pull Latest Changes**
-
-   - Fetches latest updates from remote
-
-2. **Checkout Source Branch**
-
-   - Switches to source branch
-   - Pulls latest changes
-
-3. **Checkout Target Branch**
-
-   - Switches to target branch
-   - Pulls latest changes
-
-4. **Merge Source into Target**
-
-   - Merges source branch into target
-   - Handles merge conflicts if any
-
-5. **Push Changes**
-   - Pushes merged changes to remote
-
-## Branch Naming
-
-You can use any valid Git branch names:
-
-### Common Patterns
-
-- `master` or `main` - Main branch
-- `development` or `dev` - Development branch
-- `feat/<description>` - Feature branches
-- `fix/<description>` - Bug fix branches
-- `release/<version>` - Release branches
-- `hotfix/<description>` - Hotfix branches
-
-## Handling Merge Conflicts
-
-If conflicts occur during merge:
-
-1. The command will notify you of conflicts
-2. Manually resolve conflicts in affected files
-3. Stage resolved files:
-   ```bash
-   git add <resolved-files>
-   ```
-4. Complete the merge:
-   ```bash
-   git commit
-   ```
-5. Push changes:
-   ```bash
-   git push
-   ```
-
-## Best Practices
-
-### Before Merging
-
-1. **Ensure Clean Working Directory**
-
-   ```bash
-   git status
-   ```
-
-   Commit or stash any uncommitted changes
-
-2. **Test Source Branch**
-
-   - Run tests on source branch
-   - Verify functionality works
-
-3. **Review Changes**
-   ```bash
-   git log target..source
-   ```
-   Review commits being merged
-
-### After Merging
-
-1. **Verify Merge**
-
-   - Check that all changes are included
-   - Run tests on target branch
-
-2. **Notify Team**
-
-   - Inform team members of the merge
-   - Update relevant documentation
-
-3. **Delete Feature Branch** (if applicable)
-   ```bash
-   git branch -d feat/123-feature-name
-   ```
-
-## Common Merge Scenarios
-
-### Merge Feature to Development
-
-```bash
-# After completing feature work
-nitor merge -s feat/123-user-auth -ta development
-```
-
-### Merge Development to Master
-
-```bash
-# For production release
-nitor merge -s development -ta master
-```
-
-### Merge Hotfix to Multiple Branches
-
-```bash
-# Merge to master
-nitor merge -s hotfix/critical-bug -ta master
-
-# Then merge to development
-nitor merge -s hotfix/critical-bug -ta development
-```
-
-## Troubleshooting
-
-### Merge Conflicts
-
-If you encounter conflicts:
-
-1. **Identify conflicted files:**
-
-   ```bash
-   git status
-   ```
-
-2. **Open and resolve conflicts:**
-
-   - Look for conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`)
-   - Choose the correct code
-   - Remove conflict markers
-
-3. **Complete merge:**
-   ```bash
-   git add <resolved-files>
-   git commit
-   git push
-   ```
-
-### Failed to Push
-
-If push fails:
-
-1. **Pull latest changes:**
-
-   ```bash
-   git pull
-   ```
-
-2. **Resolve any conflicts**
-
-3. **Push again:**
-   ```bash
-   git push
-   ```
-
-### Branch Not Found
-
-If source or target branch doesn't exist:
-
-1. **List available branches:**
-
-   ```bash
-   git branch -a
-   ```
-
-2. **Verify branch names are correct**
-
-3. **Fetch remote branches:**
-   ```bash
-   git fetch
-   ```
-
-## Safety Features
-
-The merge command includes safety checks:
-
-- Pulls latest changes before merging
-- Ensures branches are up-to-date
-- Validates branch existence
-- Handles merge conflicts gracefully
-
-## Getting Help
-
-To see all available options:
-
-```bash
-nitor merge -help
-```
-
-## Related Commands
-
-- `nitor create-branch` - Create new branches
-- `nitor cleanup` - Clean up merged branches
-- `nitor review` - Review merge requests

package/docs/MR_STATUS.md

@@ -1,74 +0,0 @@
-# mr-status
-
-List GitLab repositories you are a member of, pick one, and view its merge
-requests rendered as a branch tree. Useful for quickly seeing the shape of a
-stacked/chained set of MRs, what targets what, and who owns each one.
-
-## Usage
-
-```bash
-nitor mr-status [-state <opened|merged|closed|all>] [-search <text>]
-nitor mr-status [-st <state>] [-q <text>]
-```
-
-Running `nitor mr-status` with no arguments will:
-
-1. Fetch the repositories you are a member of (ordered by last activity).
-2. Prompt you to pick one by number.
-3. Prompt you to pick an MR state (defaults to `opened`).
-4. Print the selected repository's merge requests grouped by target branch as
-   a tree, showing source → target, state, author, last update time and URL.
-
-## Options
-
-- `-st`, `-state <state>` — MR state filter. One of `opened` (default),
-  `merged`, `closed`, `all`.
-- `-q`, `-search <text>` — Pre-filter the repository list by name before the
-  interactive picker is shown.
-
-## Examples
-
-```bash
-# Fully interactive
-nitor mr-status
-
-# Jump straight to opened MRs after picking a repo
-nitor mr-status -state opened
-
-# Narrow the repo picker to repos whose names contain "portal"
-nitor mr-status -search portal
-
-# Short aliases
-nitor mr-status -st merged -q gateway
-```
-
-## How the tree is built
-
-- MRs are grouped by their `target_branch`.
-- A target branch that is **not** any MR's source branch is treated as a root
-  (e.g. `master`, `development`).
-- For each MR, if its `source_branch` is itself a target of another MR, that
-  MR is nested underneath as a child — producing a readable stack of MRs.
-- Cycles (rare, but possible with odd branch setups) are detected and marked
-  with a `(cycle)` label instead of recursing forever.
-
-## Requirements
-
-The command uses the GitLab REST API and requires the following env vars in
-your `.env.nu`:
-
-- `GITLAB_URI` — e.g. `https://gitlab.com/`
-- `GITLAB_TOKEN` — personal access token with `read_api` scope
-
-If either is missing, the command exits with a clear message.
-
-## Output legend
-
-- `⎇ <branch>` — a target branch heading with the number of MRs targeting it
-- `!<iid> <title>` — the merge request, colored by state:
-  - green: `opened`
-  - blue: `merged`
-  - red: `closed`
-- `[draft]` — shown when the MR is a draft / WIP
-- Second line: `source → target  [state]  author  updated_at`
-- Third line: the MR web URL (clickable in most modern terminals)