diff --git a/posts/2025/06/25-why-i-dont-use-wordpress.md b/posts/2025/06/25-why-i-dont-use-wordpress.md
index 17f3366..d6494a1 100644
--- a/posts/2025/06/25-why-i-dont-use-wordpress.md
+++ b/posts/2025/06/25-why-i-dont-use-wordpress.md
@@ -10,8 +10,6 @@
   - cms
 ---
 
-# Why I Don’t Use CMS Platforms Like WordPress for My Site
-
 When I started planning my personal website, one of the first decisions I made was to avoid traditional [content management systems (CMS)](https://en.wikipedia.org/wiki/Content_management_system) like [WordPress](https://wordpress.org/), [Joomla](https://www.joomla.org/), or [Drupal](https://www.drupal.org/). While these platforms are widely used and well-supported, they weren’t the right fit for what I needed. My site isn’t meant to be flashy, constantly changing, or dependent on third-party plug-ins. It’s meant to be simple, fast, minimal, and under my complete control.
 
 ## Simplicity Over Features
diff --git a/posts/2025/07/16-github-site-evaluation.md b/posts/2025/07/16-github-site-evaluation.md
index eb380fe..34e7d7f 100644
--- a/posts/2025/07/16-github-site-evaluation.md
+++ b/posts/2025/07/16-github-site-evaluation.md
@@ -13,8 +13,6 @@
   - tools
 ---
 
-# GitHub Website Evaluation
-
 ## Introduction
 
 [GitHub](https://github.com) serves as a **comprehensive platform** for hosting, sharing, and collaborating on software development projects, offering essential tools like repositories, issue tracking, and project management that are crucial for tracking different project stages, managing changes, and reverting to previous states through features such as [branching and commit history](https://docs.github.com/en/get-started/using-git/about-branches).
diff --git a/posts/2025/07/16-why-i-like-git.md b/posts/2025/07/16-why-i-like-git.md
index 280a145..e91e8be 100644
--- a/posts/2025/07/16-why-i-like-git.md
+++ b/posts/2025/07/16-why-i-like-git.md
@@ -14,8 +14,6 @@
   - tools
 ---
 
-# Why I Love Git
-
 Ever rewrite your codebase with a fresh idea—confident you were on a better path—only to realize later that you actually liked the old way more?
 
 Maybe it wasn’t perfect. Maybe it was messy, inefficient, hacked together. But now, you're staring down a feature you thought you'd never need again, one you casually deleted in your so-called “superior redesign.” And you wish you could bring it back—not rewrite it, not rebuild it, just… recover it.
diff --git a/posts/2025/07/27-setup-gitbucket.md b/posts/2025/07/27-setup-gitbucket.md
new file mode 100644
index 0000000..13dce14
--- /dev/null
+++ b/posts/2025/07/27-setup-gitbucket.md
@@ -0,0 +1,181 @@
+---
+title: "GitBucket Setup and Configuration Guide"
+date: "2025-07-27"
+updated: "2025-07-27"
+slug: "setup-gitbucket"
+published: true
+layout: "blog-post"
+tags:
+  - git
+  - programming
+  - coding
+  - development
+  - productivity
+  - tools
+  - ssh
+  - database
+  - mysql
+  - postgresql
+  - dns
+  - server-setup
+  - java
+  - war-file
+---
+
+## Download the GitBucket WAR File
+
+Download the latest [GitBucket WAR file](https://github.com/gitbucket/gitbucket/releases).  
+Verify the checksum or signature before use when available to ensure the file has not been tampered with.
+
+## Running the GitBucket WAR File
+
+You can run GitBucket directly with the Java runtime:
+
+```bash
+java -jar gitbucket.war
+```
+
+Alternatively, deploy the WAR file to a servlet container (e.g., Tomcat) for integration with existing infrastructure.  
+Startup may display logging-related warnings (e.g., missing config files or logback fallback notices); these are non-fatal.  
+Use `journalctl` or your container logs to monitor the service:
+
+```bash
+journalctl -u gitbucket -f
+```
+
+## Logging and Troubleshooting
+
+System logs provide the most reliable source of error context:
+
+```bash
+sudo systemctl status gitbucket
+journalctl -u gitbucket -f
+```
+
+If GitBucket fails to start or returns generic HTTP errors, check the underlying database logs and JVM output.  
+Enable debug logging in the GitBucket configuration if you need detailed stack traces.
+
+## Configuring GitBucket for Production Use
+
+The default embedded H2 database is not persistent or scalable. For production use:
+
+1. Set up MySQL or PostgreSQL.
+2. Configure GitBucket with JDBC connection parameters.
+
+Example for PostgreSQL:
+
+```bash
+GITBUCKET_HOME=/opt/gitbucket
+cat > $GITBUCKET_HOME/database.conf <<EOF
+db.url=jdbc:postgresql://localhost:5432/gitbucket
+db.user=gitbucket_user
+db.password=secure_password
+EOF
+```
+
+Ensure the target database exists and credentials are valid.
+
+## Database Error Diagnosis
+
+GitBucket will display HTTP 500 errors for most database issues, masking the actual cause.  
+Inspect the database server logs directly:
+
+```bash
+# MySQL
+sudo tail -f /var/log/mysql/error.log
+
+# PostgreSQL
+sudo tail -f /var/log/postgresql/postgresql-*.log
+```
+
+Check for authentication failures, permission denials, invalid schema references, or dropped connections.  
+Also validate firewall rules and SELinux/AppArmor settings if applicable.
+
+## SSH Configuration for GitBucket
+
+GitBucket supports SSH-based Git operations.  
+Avoid port 22 for GitBucket’s SSH due to system constraints or shared services. Use an unprivileged high-numbered port like 29418.  
+Redirect standard port 22 to 29418 to maintain client compatibility:
+
+```bash
+iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 29418
+iptables -A INPUT -p tcp --dport 29418 -j ACCEPT
+```
+
+Persist firewall rules:
+
+```bash
+sudo iptables-save > /etc/iptables/rules.v4
+```
+
+Ensure the GitBucket instance listens on the specified SSH port. Configure this in `gitbucket.conf`:
+
+```properties
+gitbucket.ssh.port=29418
+```
+
+Restart the service after applying changes.
+
+## Network and DNS Setup
+
+If GitBucket is hosted on a VPN, container, or isolated interface, assign a static IP:
+
+```bash
+ip addr add 10.8.0.2/24 dev tun0
+```
+
+Update your DNS server or `/etc/hosts` to resolve a proper hostname:
+
+```
+gitbucket.example.com. IN A 10.8.0.2
+```
+
+DNS is essential for:
+
+- Hostname-based Git operations
+- SSL certificate issuance
+- API and webhook consistency
+- Integrations with CI/CD or other tools
+
+Allow for DNS propagation delays before testing public access.
+
+## Generating and Adding SSH Keys in GitBucket
+
+To authenticate via SSH:
+
+1. Generate a key pair on the client machine:
+
+```bash
+ssh-keygen -t rsa -b 4096 -C "user@example.com"
+```
+
+2. Copy the public key:
+
+```bash
+cat ~/.ssh/id_rsa.pub
+```
+
+3. Log into GitBucket.
+4. Navigate to **User Settings > SSH Keys**.
+5. Paste and save the public key.
+
+Ensure:
+
+- The SSH daemon is configured to accept the port used by GitBucket.
+- GitBucket's internal SSH service is running and correctly mapped to that port.
+- No firewall or SELinux rule is blocking the custom port.
+
+Test with:
+
+```bash
+ssh -T -p 29418 git@gitbucket.example.com
+```
+
+## Summary of Critical Points
+
+- Always use MySQL or PostgreSQL in production; H2 is not durable or scalable.
+- Check systemd and database logs for all unexplained HTTP errors.
+- Use a non-privileged SSH port and port-forward 22 if compatibility is needed.
+- Set a dedicated static IP and configure DNS with proper hostname resolution.
+- Upload SSH public keys into GitBucket UI for access control.
+- Validate and test each component (JVM, database, SSH, firewall) independently before final deployment.
diff --git a/workspace-docs/doc4.md b/workspace-docs/doc4.md
new file mode 100644
index 0000000..18b5c01
--- /dev/null
+++ b/workspace-docs/doc4.md
@@ -0,0 +1,85 @@
+This workspace manager differs fundamentally from tools like **Ranger**, **Yazi**, **Thunar**, **NerdTree**, and similar file explorers by shifting focus from general-purpose file navigation to **context-specific workspace control**. It is not a file browser. It is a **workspace boundary enforcer** with integrated filtering, project-aware exclusion, and action execution tuned to project state. The difference is categorical, not incremental.
+
+---
+
+### Comparison: Functional Gaps in Other Tools
+
+#### **Ranger / Yazi**
+
+- Terminal-based, directory tree navigators with image previews, vim-like controls.
+- **Lack contextual awareness**: treat all files equally regardless of file type, project type, or system role.
+- **No semantic filtering**: cannot differentiate between source files and build artifacts unless manually configured.
+- **No behavior hooks**: cannot trigger confirmation prompts or rebuilds based on file type changes.
+- **No multi-workspace support**: operate on directories, not conceptual workspaces.
+
+#### **Thunar / Nautilus / Dolphin**
+
+- GUI file managers.
+- **Not suited for terminal workflows**.
+- **Cannot segment based on project type or context**.
+- **No integration with command execution** or environment-specific behavior.
+
+#### **NerdTree / NvimTree**
+
+- IDE or editor-based project file explorers.
+- **Coupled to the editor instance**: no CLI interface or external scripting.
+- **Limited to file discovery and static filtering**.
+- **No dynamic behavior per file change** (e.g., prompt after editing a system configuration file).
+
+#### **fzf / skim + shell glue**
+
+- Generic fuzzy finders.
+- **Flat search** with no awareness of file relevance or workspace context.
+- **No persistent workspace concept**.
+- **No exclusion control** beyond basic globs.
+
+---
+
+### Similar Tools (Functionally or Conceptually)
+
+Some tools attempt partial overlaps:
+
+- **Taskwarrior** (context-based task filtering): Similar in scope isolation, but for tasks.
+- **Direnv** (directory-based environment control): Environment-sensitive, but no file filtering or actions.
+- **Project-based shell wrappers (e.g. tmuxinator, zellij layouts)**: Focus on terminal state, not file context or control.
+- **Telescope.nvim with project plugins**: Closer in spirit, but editor-bound and lacks filtering persistence or dynamic exclusions.
+- **Ripgrep-all** + `fd` + `jq` pipelines: DIY pipeline solutions, brittle and not aware of project semantics.
+
+None combine **filtering, exclusion, workspace logic, and controlled behavior execution** into a coherent, reusable, terminal-native system.
+
+---
+
+### What This Program Does Better
+
+#### 1. **Semantic Workspace Boundaries**
+
+It understands **project type** and adjusts behavior accordingly—e.g., filtering only `.nix` files and known configuration directories in a Nix context. Other tools operate generically, requiring user-supplied knowledge and constant reconfiguration.
+
+#### 2. **Integrated Contextual Actions**
+
+Users can define **active behavior** on file interactions. Example: editing a `.nix` file triggers a rebuild confirmation prompt. This binds file types to safe operational flow. File managers don’t know or care what actions are appropriate for each file.
+
+#### 3. **Multi-Workspace Management**
+
+Simultaneous, switchable contexts tailored to different languages, configurations, and projects. Each workspace retains its filters, exclusions, and behavior logic. Most file tools operate globally or per session without context persistence.
+
+#### 4. **Persistent, Layered Filtering**
+
+Combines directory filters, file extensions, regex patterns, and version control awareness to precisely tailor what files are shown or acted on. This eliminates clutter and focuses the user on exactly what matters, with no need for interactive filtering commands.
+
+#### 5. **Clipboard Integration for Extracted Code**
+
+With its companion tools, it can extract specific functions, classes, or marked blocks from files and send them to the clipboard for rapid sharing or documentation—something file browsers and even most editors do not handle gracefully.
+
+#### 6. **Controlled Environment Mutation**
+
+It does not just present files. It **governs what happens** when files are modified or selected, enforcing workflows that prevent mistakes (e.g., unprompted rebuilds or accidental edits to generated files).
+
+---
+
+### Systemic Advantage
+
+This program **creates an operational perimeter** around the user’s intent. It reduces the chance of mistakes by excluding irrelevant files and directories, prevents damaging operations by introducing explicit checkpoints, and allows seamless switching between distinct contexts without cross-contamination. It eliminates the need to remember directory-specific commands, filters, or conventions. Its power lies in enforcing strict, contextual discipline in environments where errors are expensive or configuration surfaces are broad.
+
+File managers let you see everything.
+This tool ensures you only see what you need—and only act when it’s safe.
diff --git a/workspace-docs/toolkit/toolkit6.md b/workspace-docs/toolkit/toolkit6.md
new file mode 100644
index 0000000..3337336
--- /dev/null
+++ b/workspace-docs/toolkit/toolkit6.md
@@ -0,0 +1,51 @@
+This toolkit surpasses traditional shell aliasing and PATH-based executable discovery in five critical dimensions: organization, discoverability, contextual awareness, execution safety, and cognitive ergonomics. While aliases and PATH additions streamline command execution by reducing keystrokes or surfacing scripts, they lack structural clarity, scalability, and feedback mechanisms. This toolkit addresses those gaps directly.
+
+---
+
+### Comparison with Shell Aliases and PATH Augmentation
+
+**1. Structural Clarity vs. Flatness**
+Aliases are flat key-value mappings with no inherent hierarchy. As they grow in number, they become opaque and unmanageable. PATH-based scripts suffer the same problem: the more executables are dropped into directories, the less coherent the system becomes. This toolkit introduces nested categorization, which reflects logical domain groupings—system management, networking, version control, etc.—enabling users to browse and select commands within structured contexts rather than relying on memory or naming conventions.
+
+**2. Discoverability vs. Memorization**
+Aliases and scripts demand recall. If a user forgets the alias name or script path, they must grep `.zshrc`, search their shell history, or maintain external documentation. The toolkit presents a browsable interface with descriptive titles, allowing users to locate the right operation through recognition rather than recall. This reduces memory burden and speeds up task initiation.
+
+**3. Contextual Prompts vs. Blind Execution**
+Aliases and scripts execute blindly. They do not prompt for confirmation, show previews, or adapt based on context unless additional wrappers are written. This toolkit supports embedded dialog prompts, visual feedback, and branching behavior, guiding the user to correct input and reducing the chance of misexecution in sensitive operations.
+
+**4. Execution Safety vs. Command Line Risk**
+Aliases and PATH scripts do not inherently reduce the risk of running the wrong command with the wrong arguments. They offer no guardrails. This toolkit structures commands with contextual cues, description fields, and optional preview functionality, creating an execution environment designed to prevent human error before it occurs.
+
+**5. Scalability and Modularity vs. File Sprawl**
+As teams grow or environments diversify, alias files and PATH directories become fragmented and inconsistent across systems. This toolkit’s nested configuration model is inherently modular, portable, and version-controllable, making it suitable for both individual and team-based environments with diverse infrastructure roles.
+
+---
+
+### Comparable Tools
+
+**fzf + alias-driven menus:**
+Tools like `fzf` combined with shell aliases provide fuzzy searching over aliases or command history, improving discoverability. However, these require ad-hoc glue code and lack persistent structure, description metadata, or guided execution.
+
+**taskwarrior / taskell (for todo workflows):**
+While focused on task management, these tools use structured, CLI-based UIs to improve workflow clarity. The toolkit applies a similar principle to command execution rather than task tracking.
+
+**tmuxinator / zellij layouts:**
+Tools that script terminal layouts (e.g., tmuxinator) predefine environment states but focus on session arrangement, not execution workflows. This toolkit complements such tools by focusing on the actual commands and workflows inside the environment.
+
+**rofi / dmenu + custom scripts:**
+These can present dynamic command menus but lack native nesting, contextual descriptions, or safe execution features unless manually implemented.
+
+**Cheat.sh / TLDR pages / DevDocs:**
+These assist with syntax recall but are read-only and require manual execution afterward. This toolkit embeds execution directly, transforming command reference into command action.
+
+---
+
+### Advantages Over All Alternatives
+
+- **Nested categories** prevent overload and support logical grouping, unlike flat alias systems.
+- **Descriptive metadata** ensures users understand what each command does before running it.
+- **UI integration** with prompts, dialogs, and previews ensures safe and informed execution.
+- **Portability** of configuration enables consistent environments across teams and machines.
+- **Real-time interaction** transforms static reference into dynamic operations.
+
+In sum, this toolkit is not just an alias manager, a script launcher, or a fuzzy finder. It is a terminal-native command orchestration layer, purpose-built to align command-line workflows with human cognitive structure. It elevates precision, recall, safety, and adaptability, replacing fragile shell customizations with a structured, discoverable, and scalable interface designed for serious, error-intolerant work.
diff --git a/workspace-docs/toolkit/toolkit7.md b/workspace-docs/toolkit/toolkit7.md
new file mode 100644
index 0000000..4f5aa06
--- /dev/null
+++ b/workspace-docs/toolkit/toolkit7.md
@@ -0,0 +1,17 @@
+This toolkit is a command execution and workflow orchestration environment purpose-built for terminal users who demand speed, context-awareness, and flexibility. Unlike traditional shell aliasing or modifying the PATH variable, which require memorization, static mappings, and flat command execution, this tool provides a cohesive interactive layer that brings structured discoverability, intelligent navigation, and guided interaction to complex command usage.
+
+The interface functions like a dynamic command palette tailored for the terminal. Users can visually browse, select, modify, and execute commands within a focused, keyboard-driven environment. Commands are organized logically, with contextual cues and grouped by function or intent. Rather than relying on external documentation, trial-and-error, or fragmented shell history, users are presented with a consistent, explorable interface that brings visibility and coherence to their command-line operations.
+
+This toolkit significantly enhances workflows for system administrators, DevOps professionals, and power users managing large sets of repetitive or error-prone tasks. For example, a user managing containerized environments can quickly jump between command groups for building, launching, inspecting, or tearing down systems, each with customized parameters and live feedback. The command input field adapts to input patterns and encourages precision without being rigid, reducing input errors and unintentional destructive operations. Confirmations, visual separators, and guided dialogs further mitigate risk when running sensitive commands.
+
+In scenarios such as infrastructure maintenance, daily report generation, or log inspection, users benefit from seamless transitions between commands and visual components like confirmation prompts or dynamic panes. These UI elements surface just-in-time and withdraw without clutter, offering a balance between interactivity and minimalism. The interface accommodates decision points with clarity, keeping users in flow without forcing context switches.
+
+The toolkit improves productivity by reducing friction in every layer of command execution: discovery, recall, input, execution, and output review. It eliminates the need for secondary documentation or shell tricks by exposing structured command history, reusability, and context-aware options. Commands are not just invoked but integrated into an ongoing session that respects user state and intent.
+
+Compared to alternatives such as `fzf`, `peco`, or basic command launchers, this toolkit offers a broader operational model. It combines command browsing, parameter editing, dialog-driven workflows, and terminal UI components in a unified experience. While tools like `fzf` accelerate fuzzy recall of known commands, they lack the structured interaction and session awareness this toolkit provides. Shell aliases, while convenient, are opaque, flat, and difficult to scale or share across teams. This toolkit encourages standardized command usage, self-documentation, and consistency without sacrificing customization.
+
+From a user perspective, this system scales naturally with complexity. It grows with the user's command vocabulary and adapts to increasingly sophisticated workflows. Commands can be grouped and retrieved based on task domain, reducing decision fatigue and enabling team-wide command patterns. Collaboration is supported by the fact that command definitions and workflows become visible, navigable, and discussable—unlike hidden aliases or brittle shell scripts.
+
+Customization is straightforward from a user standpoint. Commands and layouts adjust to operational context, while the interface remains familiar and efficient across diverse tasks. The toolkit respects traditional terminal muscle memory, offering full keyboard operability and responsiveness, while enhancing visibility and interaction for users managing high-stakes systems or high-volume workflows.
+
+In essence, this toolkit transforms the terminal from a linear command input interface into an interactive operations dashboard—one where commands are not only executed, but understood, managed, and refined as part of a broader operational flow. It brings clarity, safety, and structure to environments where precision, repeatability, and speed are essential.
diff --git a/workspace-docs/toolkit/toolkit8.md b/workspace-docs/toolkit/toolkit8.md
new file mode 100644
index 0000000..7e63479
--- /dev/null
+++ b/workspace-docs/toolkit/toolkit8.md
@@ -0,0 +1,11 @@
+The safe help discovery feature is designed to provide immediate, clear, and context-sensitive guidance without disrupting workflow or risking accidental command execution. Within the command browser’s command pane, each command is accompanied by an integrated description that serves as an informative reference, revealing its purpose, expected effects, and usage nuances before any action is taken.
+
+This description is not merely static text; it is dynamically tailored to the command’s context and parameters, enabling users to understand precisely what the command will do in the current state. By surfacing this information directly alongside the command, users can assess the relevance and potential impact of the command without needing to leave the interface or consult external documentation.
+
+The integration ensures that commands with potentially destructive or complex effects carry explicit warnings or confirmation cues within their descriptions, highlighting risks and necessary precautions. This upfront visibility reduces the likelihood of mistakes caused by misunderstanding or memory lapses.
+
+Safe help discovery is also embedded in the interactive flow: when users navigate or filter commands, the descriptions update in real time to reflect the active selection. This immediate feedback loop encourages exploration and learning, allowing users to build command familiarity safely and incrementally.
+
+Because the command pane’s description is fully keyboard-navigable and appears without triggering execution, users can thoroughly investigate commands’ behaviors and parameters without any operational side effects. This separation of discovery and execution phases safeguards the environment while promoting confident command usage.
+
+Overall, the feature merges assistance and safety by embedding rich, actionable knowledge directly into the command selection process, transforming command browsing into a low-risk, high-confidence interaction that enhances user autonomy and reduces dependency on error-prone recall or external help sources.