Update/deployment

CHANGELOG.md

@@ -4,6 +4,81 @@ Completed repository changes, newest first. Tracking begins on 2026-10-05;
 earlier work has not been reconstructed. Planning and archive rules are in
 [AGENTS.md](AGENTS.md#task-plans-and-documentation).
 
+## 2026-10-11 — Rename the local workspace folder
+
+- Rename `/Users/hemant/pers/alert_ops` to `/Users/hemant/pers/replytrail`,
+  preserving files, Git metadata, and all uncommitted work.
+- Verify the new working directory, unchanged Git status and origin, and diff
+  checks. Reopen the workspace at the new path; no application code changed.
+
+## 2026-10-11 — Align links with the ReplyTrail repository rename
+
+- Update local origin fetch/push URLs and current documentation links to
+  `1hemant2/replytrail`; preserve runtime compatibility identifiers and the
+  existing workspace directory.
+- Document repository-derived GHCR naming and the need to verify new image
+  publication before deployment. No images or cloud resources were migrated.
+- Verify GitHub's canonical URL, local remotes, documentation file links, and
+  whitespace; Maven verify passes with opt-in integration checks skipped.
+  No old repository URLs remain in the searched source tree.
+
+## 2026-10-11 — Prepare open-source hosting applications
+
+- Correct first-email timing and VM-hosting descriptions; add contribution and
+  security-reporting guidance without changing application behavior.
+- Prepare an [unsent hosting request](docs/deployment/hosting-request.md) with
+  honest adoption and resource limits. GitHub description text is provided for
+  manual update; sponsorship and private vulnerability reporting are not enabled
+  by this change.
+- Verification: relative documentation file links and diff checks pass; Maven
+  verify passes outside the sandbox. Opt-in integration/deployed checks remain
+  unverified; no applications were submitted.
+
+## 2026-10-11 — Show the feature guide on the public home page
+
+- Add a responsive, accessible feature guide to the public landing page with
+  header and hero anchors, light/dark theme styling, and concise explanations of
+  the current ReplyTrail workflow.
+- Keep product boundaries visible by stating that unsupported channels and
+  deferred test escalations are not included in the current product.
+- Verification: UI build and diff checks pass. UI lint passes with two existing
+  React hook warnings in the flow detail page; no new warnings were introduced.
+
+## 2026-10-11 — Publish the ReplyTrail feature guide
+
+- Add a single [feature guide](docs/features.md) with stable feature IDs,
+  human-readable workflows, canonical lifecycle and security rules, API areas,
+  implementation status, and deferred boundaries for people and AI agents.
+- Link the guide from the README and align scheduling scope text with the local
+  daily/weekly recurrence implementation. Preserve the distinction between local
+  implementation and pending PostgreSQL/deployed verification.
+- Verification: documentation links and whitespace checked with `git diff --check`;
+  no backend or frontend behavior changed.
+
+## 2026-10-11 — Clean up old Oracle deployment and prepare minimal test hosting
+
+- Remove the approved old OKE cluster, worker pool, two A1 workers, and three
+  47 GB boot volumes; retain the compartment and network. Boot-volume data was
+  permanently deleted. Install OCI CLI and establish local authenticated access.
+- Document the Oracle ARM64 test target and dedicated SSH access in the
+  [deployment guide](docs/deployment/README.md). The 1 OCPU / 4 GB / 50 GB VM
+  launch failed; the reduced 1 OCPU / 2 GB target also lacks capacity in all
+  Mumbai fault domains and needs lower Compose limits plus load testing. No new
+  VM or application deployment was created, and the task remains pending.
+- Verify successful OKE cleanup, terminated workers/volumes, capacity reports,
+  backend packaging with tests skipped, and diff checks. CI/CD remains pending.
+
+## 2026-10-11 — Separate Kubernetes materials from the first release
+
+- Move Kubernetes manifests and historical deployment learning guides into the
+  separate local repository `/Users/hemant/pers/replytrail-kubernetes`; retain
+  Docker, Compose, and CI here. Preserve the archive alongside the application
+  so the deployment learning journey can continue later.
+- Update the [deployment guide](docs/deployment/README.md) and release checklist
+  for the agreed EC2/Compose direction. Production setup and deployment remain pending.
+- Verification: all 18 archived files match Git history, updated links resolve,
+  backend packaging with tests skipped and diff checks pass.
+
 ## 2026-10-11 — Implement minimum recurring escalation runs
 
 - Implement daily/weekly repeat support on the existing escalation row with

CONTRIBUTING.md

@@ -0,0 +1,31 @@
+# Contributing to ReplyTrail
+
+ReplyTrail welcomes bug reports, documentation improvements, and focused code
+contributions. The project is MIT-licensed and is still preparing its first
+deployed release; see the [launch checklist](docs/product-launch-readiness.md).
+
+## Report an issue
+
+Use [GitHub issues](https://github.com/1hemant2/replytrail/issues) for ordinary bugs
+and feature discussions. Include the version or commit, reproduction steps,
+expected behavior, and actual behavior. Remove credentials, email action tokens,
+personal data, and sensitive logs. Follow [SECURITY.md](SECURITY.md) for security
+reports instead of publishing vulnerability details.
+
+## Make a change
+
+1. Discuss substantial behavior or architecture changes in an issue first.
+2. Fork the repository and create a focused branch from `master`.
+3. Follow [AGENTS.md](AGENTS.md), including the current-plan, naming, test, and
+   changelog rules. Use the [README](README.md#run-locally) to set up locally.
+4. Add focused tests for changed behavior and run the commands in
+   [Development checks](README.md#development-checks). State which integration
+   or deployed checks were skipped and why.
+5. Open a pull request against `master`. Explain the problem, the change, and
+   verification results. Keep unrelated work out of the pull request and keep
+   backend, frontend, tests, and documentation in separate commits.
+
+Preserve PostgreSQL as the durable source of truth, in-memory timers as wake-up
+handles, and RabbitMQ as the ready-work queue. Never commit `.env` files, private
+keys, provider credentials, or real user data. Contributions remain under the
+repository's [MIT license](LICENSE.md).

README.md

@@ -2,6 +2,8 @@
 
 **Keep every response on track.**
 
+The source repository is [1hemant2/replytrail](https://github.com/1hemant2/replytrail).
+
 ReplyTrail is a self-hosted web application for team response coordination. Turn an alert or request into a task, choose an ordered path of people to notify, and track the response from the first email to acknowledgement or resolution. If nobody responds within the configured wait, the run advances to the next person.
 
 It helps teams answer three questions: **Who should respond? When should the next person be notified? What happened to this request?** A team member can start a run in the UI, schedule it for later, or let an external system trigger it through a webhook. This repository contains the React UI, Spring Boot API and workers, database migrations, and deployment configuration.
@@ -34,14 +36,14 @@ You can also connect another tool through a webhook to send tasks to ReplyTrail.
 That tool detects the problem and sends the details; ReplyTrail emails the
 people you choose. They carry out the work in the relevant app or system.
 
-### Example: daily reminders for ten days
+### Example: ten reminders spaced one day apart
 
 Create a flow with ten steps and put your own team-member email on every step.
 Set each wait to **1,440 minutes (24 hours)** and leave **resolution timeout**
 disabled. Start it with the task you want to be reminded about.
 
-The first reminder is scheduled for 24 hours after you start. Each later
-reminder is scheduled for 24 hours after the previous email is sent. If you
+The first reminder is sent as soon as the run starts. Each later
+reminder becomes due 24 hours after the previous email is sent. If you
 click **Acknowledge** and confirm, the remaining reminders stop.
 
 If you do not acknowledge, the ten-step sequence continues and then ends;
@@ -61,10 +63,13 @@ emails arrive, so they may not reach you at the same clock time every day.
 
 ## Features
 
+The [feature guide](docs/features.md) explains each feature's purpose, actors,
+workflow, lifecycle rules, API area, and verification status.
+
 - **Accounts and teams:** Registration requires email verification before login. Users can belong to multiple teams. Owners and admins can invite members; admins can invite users only. Acceptance requires the invited, verified email address.
 - **Tasks:** Name, description, and source, plus optional priority, category, and HTTP(S) reference URL. Priority is a user-defined label. Manually created tasks default to source `Manual`.
 - **Response paths:** Ordered steps with a team-member recipient and wait time, plus optional resolution timeouts. Add, edit, delete, and drag steps to reorder them. Started runs retain their saved task context, step details, and timing when a task or path changes.
-- **Immediate or scheduled runs:** Start a run from a task and path immediately, or schedule a one-time start using a date, time, and IANA timezone. Reschedule, cancel, or start a scheduled run early before it begins. The first step keeps its configured wait.
+- **Immediate, scheduled, and recurring runs:** Start a run from a task and path immediately, schedule a one-time start using a date, time, and IANA timezone, or repeat a schedule daily or weekly. Reschedule, cancel, stop future repeats, or start a scheduled run early before it begins. The first email is sent immediately when the run starts; its configured acknowledgement wait begins after delivery.
 - **Webhooks:** Owners and admins can create a webhook with a default path, rotate its secret, and enable or disable it. An incoming event creates a task and starts a run. The complete JSON event is stored with links to both records.
 - **Acknowledgement and resolution:** Recipient-scoped email links open a preview before confirmation. Acknowledgement either completes the run or pauses later steps for a configured resolution window. Unresolved timeouts resume escalation; resolution stops remaining steps.
 - **Manual escalation:** Escalate now makes the next eligible response step due immediately from the signed-in UI or an eligible email action link.
@@ -74,7 +79,7 @@ emails arrive, so they may not reach you at the same clock time every day.
 ## Current scope
 
 - Notifications use **SMTP email**. SMS, phone calls, push notifications, and native Slack/Teams delivery are not implemented.
-- Scheduling supports **one-time starts**, not recurring or cron schedules. A finite reminder sequence can use multiple steps assigned to the same person, as in the ten-day example above.
+- Scheduling supports one-time starts and the minimum daily/weekly recurrence implementation. Monthly, yearly, custom-interval, and cron schedules are not implemented. A finite reminder sequence can still use multiple steps assigned to the same person, as in the ten-reminder example above.
 - A response path names individual team-member recipients; rotating on-call calendars are not implemented.
 - Opening an email link does not accept responsibility automatically; the recipient must confirm the action.
 - Local checks do not establish production readiness. Database/broker integration checks and deployed response journeys are tracked in the launch checklist.
@@ -112,7 +117,7 @@ PostgreSQL stores tasks, paths, events, runs, step states, and due times. The ba
 | Ready-work delivery | RabbitMQ; database-backed timers determine when work becomes ready |
 | Short-lived shared state | Redis for workflow intents and webhook rate limiting |
 | Email | Spring Mail with an SMTP provider |
-| Packaging and deployment | Docker Compose for local services; Kubernetes manifests and GitHub Actions for backend build, verification, and image scanning |
+| Packaging and deployment | Docker Compose for local services and planned VM hosting; GitHub Actions for backend build, verification, and image scanning |
 
 The UI can be deployed as static files separately from the backend. Existing `com.alertops` packages, `ALERTOPS_*` settings, container/resource names, and the `X-AlertOps-Webhook-Secret` header are retained compatibility identifiers from the earlier product name. Use these exact identifiers in configuration and integrations.
 
@@ -250,6 +255,9 @@ Stop Compose services with `docker compose down`. `docker compose down -v` also
 
 ## Development checks
 
+Contributions are welcome. Read [CONTRIBUTING.md](CONTRIBUTING.md) for the workflow
+and [SECURITY.md](SECURITY.md) before reporting a potential vulnerability.
+
 From the repository root:
 
 ```bash
@@ -270,7 +278,9 @@ The backend command runs tests and packages the application; the UI build checks
 - `docker-compose.yml`: local backend and dependency stack.
 - `.github/workflows/ci.yml`: Maven verification, container build, and Trivy image scan on pull requests and configured branch pushes.
 - [`docs/product-launch-readiness.md`](docs/product-launch-readiness.md): release checklist and remaining end-to-end checks.
-- [`docs/deployment/README.md`](docs/deployment/README.md): staged deployment learning plan.
+- [`docs/features.md`](docs/features.md): human- and AI-readable feature guide.
+- [`docs/deployment/README.md`](docs/deployment/README.md): first-release hosting and Docker Compose deployment direction.
+- [`docs/deployment/hosting-request.md`](docs/deployment/hosting-request.md): an unsent open-source test-hosting request and application preparation guidance.
 - [`CHANGELOG.md`](CHANGELOG.md): completed repository changes and verification notes.
 
 Manual and webhook response flows, one-time scheduling, resolution timeouts, manual actions, and activity history are implemented locally. The release checklist still calls for deployed end-to-end runs, including restart and duplicate-delivery scenarios. Domain ownership, sender verification, and rebrand rollout are tracked in the [product rebranding plan](docs/product-rebranding-plan.md).

SECURITY.md

@@ -0,0 +1,21 @@
+# Reporting a security issue
+
+Do not publish vulnerability details, exploit code, credentials, private keys,
+or email action tokens in public issues or pull requests.
+
+Use GitHub's **Report a vulnerability** option in this repository's
+[Security tab](https://github.com/1hemant2/replytrail/security) if it is available.
+This option depends on the owner enabling private vulnerability reporting.
+If it is unavailable, open an issue titled “Request a private security contact”
+with no vulnerability details, and wait for the maintainer to provide a private
+channel before sharing the report.
+
+In the private report, include the affected commit, the impact, reproduction
+steps using synthetic data, and any suggested mitigation. Redact secrets and
+personal data. Do not test against systems or accounts you do not own or have
+explicit permission to assess.
+
+ReplyTrail is preparing its first deployed release. There is no published
+security-support window, guaranteed response time, or bug-bounty program.
+Report the affected version even if it is older; review and fixes are handled
+as maintainer capacity permits.

docs/current-plan.md

@@ -1,50 +1,33 @@
 # Current task plan
 
-## Task: Implement minimum recurring escalation schedules
+## Task: Rename the local ReplyTrail workspace folder
 
 Started: 2026-10-11
-Status: Complete — local implementation finished; deployment remains pending
+Status: Complete
 
 ### Goal and scope
 
-Implement the minimum recurring schedule scope from the [feature plan](recurring-escalation-implementation-plan.md)
-while preserving one-time escalation behavior. This task includes backend,
-frontend, migrations, focused tests, and documentation updates; deployment remains
-excluded and is the final release step.
+Rename `/Users/hemant/pers/alert_ops` to `/Users/hemant/pers/replytrail` as
+explicitly requested. Preserve all files, Git metadata, and uncommitted changes.
 
 ### Decision-compliance note
 
-- Preserve the existing one-time schedule and escalation lifecycle.
-- Each occurrence has a new escalation ID; overlapping runs are allowed.
-- The existing escalation table owns repeatType, nextRepeatAt, and repeatSourceId.
-  The original row owns repetition; children never own a repeating chain.
-- PostgreSQL owns calendar progress and run state; timers only provide wake-ups.
-- Reuse each run's scheduledStartAt and existing start/retry/publication path.
-- Exclude a new schedule entity/table, duplicate repeat boolean, separate schedule
-  lifecycle, and custom intervals unless separately agreed.
-- Minimum defaults are daily/weekly, scheduled first start, latest missed repeat
-  only, and stop without editing. Do not introduce repeat-after-completion,
-  monthly/yearly, custom intervals, or a separate schedule table.
-
-### Acceptance criteria
-
-- [x] Add the three recurrence fields and daily/weekly calendar calculation.
-- [x] Create independent child runs atomically and recover repeat timers safely.
-- [x] Add stop-repeat and the existing-screen scheduling controls.
-- [x] Run focused backend/frontend checks and update readiness documentation.
-
-### Steps and verification
-
-- [x] Inspect existing scheduling, execution, timer guidance, and launch tracking.
-- [x] Confirm the canonical fields, minimum defaults, and excluded improvements.
-- [x] Implement backend persistence, occurrence creation, timer recovery, and API.
-- [x] Implement the existing UI controls and source-run context.
-- [x] Run focused tests, normal builds, and diff checks; record limitations.
-
-### Verification results
-
-`EscalationRepeatCalculatorTest` passes. Backend test compilation and packaging,
-UI build, UI lint, and `git diff --check` pass; UI lint retains two existing
-warnings in `FlowDetailPage.tsx`. The full Mockito-backed service suite could not
-start because Byte Buddy cannot self-attach on this local JDK/process environment.
-PostgreSQL, broker, SMTP, restart, and deployed checks remain intentionally last.
+- Do not overwrite an existing destination or change runtime identifiers.
+- Keep the existing Git origin and historical documentation unchanged.
+- No commits, rebuilds, cloud changes, or process restarts are required.
+
+### Acceptance criteria and steps
+
+- [x] Inspect working tree and confirm the destination does not exist.
+- [x] Rename the exact folder without replacing another directory.
+- [x] Verify Git status, origin, and file preservation from the new path.
+- [x] Record the outcome and any workspace-session limitations.
+
+### Verification
+
+The directory rename succeeded. Git status retains the same modified/untracked
+files; origin fetch/push still point to `1hemant2/replytrail`. Diff checks pass.
+Reopen the workspace at the new path; shells or tools using the old absolute
+path need updating. No source behavior changed, so builds were not rerun.
+The repository-link task is complete in the changelog. Oracle deployment
+remains blocked by capacity; resume via the [deployment guide](deployment/README.md).