refactor(user): decompose createUserIfNotExists into staged pipeline; align naming with updateUserPipeline

[Copilot]

The monolithic createUserIfNotExists was structurally inconsistent with updateUserPipeline (stage-decomposed) and semantically misnamed (imperative/conditional vs structural). This migrates the full codebase to fp-go v2 IOEither pipelines and refactors the create-user flow to match the update-user pattern.

Foundation: fp-go v2 migration

• types.go — shared pipeline parameter structs (ConnectionParams, WithClient, UserParams, DatabaseParams, UserGrantParams, UserWithGrant)
• logger.go — slog-based structured logging, replacing logrus
• connection.go — createArangoClient as IOEither pipeline; toEither/foldIOE utilities
• database.go — createSingleDatabase, createUserAndGrant, grantSingleDatabase as fp-go pipelines
• main.go — drops logrus getLogger, adopts newLogger

Refactor: createUserPipeline staged decomposition

Renamed createUserIfNotExists → createUserPipeline and decomposed the monolith into explicit named stages parallel to updateUserPipeline:

// Before: monolithic F.Pipe2 with inlined F.Ternary branches
func createUserIfNotExists(p UserParams) IOE.IOEither[error, F.Void] { ... }

// After: orchestrator delegates to named stages
func createUserPipeline(p UserParams) IOE.IOEither[error, F.Void] {
    return F.Pipe2(p, checkUserExistence, IOE.Chain(routeUserCreation(p)))
}
func checkUserExistence(p UserParams) IOE.IOEither[error, bool]                          { ... }
func routeUserCreation(p UserParams) func(bool) IOE.IOEither[error, F.Void]              { ... }
func createNewUser(p UserParams) IOE.IOEither[error, F.Void]                             { ... }

Tests

• TestCreateUserIfNotExistsNewUser/Idempotent → TestCreateUserPipelineNewUser/Idempotent
• Added unit tests for createUserPipeline, updateUserPipeline, createArangoClient, createSingleDatabase, grantSingleDatabase

Original prompt

[Chronological Review: The conversation had three main phases. Phase 1: the user asked, “Lets brainstorm if in UpdateUser updateuserPipeline code/Pipe can be collapsed into the parent Pipe. Let me know what you think first”. The agent logged intent, created a SQL todo, dispatched an exploration task to inspect the Go repo, then directly viewed `user.go`, `user_test.go`, and `types.go` to verify exact code structure. Based on that, the agent concluded the nested `updateUserPipeline` can be collapsed technically, but keeping it likely preserves readability and testability. Phase 2: the user asked, “Can the function createUserIfNotExists be refactor into similar concepts, brainstorm and explain. Also the name does not semantically matches with update user pipeline.” The agent again logged intent, created a SQL todo, dispatched a repo exploration task, and then directly viewed `user.go`, `database.go`, and `user_test.go`. It concluded `createUserIfNotExists` can be refactored into a similar orchestrator/stage pipeline shape, and that naming is inconsistent with `updateUserPipeline`; it suggested names like `createUserPipeline` and possibly renaming update to `updateExistingUserPipeline`. Phase 3: the user asked, “How can i delegate this task as a github PR and a remote copilot agent handle it ? Tell me how ?” The agent fetched GitHub Copilot CLI documentation and answered that the user should use `/delegate` in Copilot CLI, with `/tasks` to monitor and `/pr` to inspect the resulting PR. Immediately after that, the user requested a comprehensive summary, which triggered this summarization.] [Intent Mapping: Explicit user requests were: (1) brainstorm whether `UpdateUser`’s nested `updateUserPipeline` can be collapsed into the parent pipe and provide an opinion first; (2) assess whether `createUserIfNotExists` can be refactored into similar concepts and explain, including addressing the semantic mismatch in naming with `updateUserPipeline`; (3) explain how to delegate this refactor as a GitHub PR to a remote Copilot agent. Implicit expectations: the user wanted design-level reasoning before code changes, consistency across create/update flows, awareness of testability and abstraction tradeoffs, and finally a practical workflow for handing implementation off to GitHub Copilot’s remote coding agent.] [Technical Inventory: Technologies/frameworks/tools involved: Go codebase at `/Users/sba964/Projects/devenv/golang/arangoadmin`; ArangoDB driver (`github.com/arangodb/go-driver`); fp-go functional combinators including `F.Pipe*`, `IOE.IOEither`, `E.FromPredicate`, `IOE.Chain`, `IOE.MapLeft`, `IOE.ChainFirstIOK`, `IOE.MapTo`; urfave CLI v3 (`github.com/urfave/cli/v3`); logging via `slog`; tests using `require`; internal SQL todo tracking tool for session progress; GitHub Copilot CLI docs for delegation flow. Architectural concepts discussed: parent command pipeline for CLI/setup, nested domain pipelines for user operations, orchestrator + stage decomposition, idempotent create flow versus strict update flow, and naming consistency across pipeline abstractions.] [Code Archaeology: Files/functions/types discussed or inspected: `user.go`: `CreateUser`, `createUserIfNotExists`, `UpdateUser`, `updateUserPipeline`, `checkUserExists`, `getExistingUser`, `withExistingUser`, `updateExistingUser`, `UserForUpdate`; `types.go`: `ConnectionParams`, `WithConnection`, `WithClient`, `UserParams`, `DatabaseParams`, `UserGrantParams`, `UserWithGrant`, `connParamsFromCmd`; `user_test.go`: `TestCreateUserIfNotExistsNewUser`, `TestCreateUserIfNotExistsIdempotent`, `TestUpdateUserPipelineSuccess`, `TestUpdateUserPipelineNonExistent`; `database.go`: `createUserAndGrant`. No repository files were modified; all work was analysis-only. Key code patterns: `UpdateUser` is a `F.Pipe5` ending in `IOE.Chain(updateUserPipeline)` and `foldIOE[F.Void]`; `updateUserPipeline` is a `F.Pipe3` chaining `checkUserExists`, `getExistingUser`, and `updateExistingUser`; `createUserIfNotExists` is a monolithic `F.Pipe2` with `UserExists` check and `F.Ternary` branching to either log existing user or create/log new user; `createUserAndGrant` duplicates similar existence-check/create-or-fetch logic.] [Progress Assessment: Completed: analysis of whether `updateUserPipeline` can be collapsed into the parent pipe; analysis of whether `createUserIfNotExists` can be reshaped into a pipeline abstraction and how naming could be aligned; explanation of how to delegate the task to a remote GitHub Copilot coding agent using Copilot CLI. Pending: no code changes were made; if continuing, likely next steps would be drafting a concrete refactor plan or a delegation prompt for Copilot. The agent suggested high-level directions but did not implement any rename/refactor.] [Context Validation: Critical continuation context captured includes: exact functions and files involved; the distinction between the update path’s strict failure semantics and the create path’s idem...

Created from Copilot CLI via the copilot delegate command.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[cybersiddhu]

Closing in favor of #24, which carries the same change rebased onto refactor/migrate-to-fp-go-v2.