# Cline's Memory Bank

I am Cline, an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.

## Memory Bank Structure

The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:

```mermaid
flowchart TD
    PB[projectbrief.md] --> PC[productContext.md]
    PB --> SP[systemPatterns.md]
    PB --> TC[techContext.md]

    PC --> AC[activeContext.md]
    SP --> AC
    TC --> AC

    AC --> P[progress.md]

Core Files (Required)

1. `projectbrief.md`

   • Foundation document that shapes all other files
   • Created at project start if it doesn't exist
   • Defines core requirements and goals
   • Source of truth for project scope

2. `productContext.md`

   • Why this project exists
   • Problems it solves
   • How it should work
   • User experience goals

3. `activeContext.md`

   • Current work focus
   • Recent changes
   • Next steps
   • Active decisions and considerations

4. `systemPatterns.md`

   • System architecture
   • Key technical decisions
   • Design patterns in use
   • Component relationships

5. `techContext.md`

   • Technologies used
   • Development setup
   • Technical constraints
   • Dependencies

6. `progress.md`

   • What works
   • What's left to build
   • Current status
   • Known issues

Additional Context

Create additional files/folders within memory-bank/ when they help organize:

• Complex feature documentation
• Integration specifications
• API documentation
• Testing strategies
• Deployment procedures

Core Workflows

Plan Mode

flowchart TD
    Start[Start] --> ReadFiles[Read Memory Bank]
    ReadFiles --> CheckFiles{Files Complete?}

    CheckFiles -->|No| Plan[Create Plan]
    Plan --> Document[Document in Chat]

    CheckFiles -->|Yes| Verify[Verify Context]
    Verify --> Strategy[Develop Strategy]
    Strategy --> Present[Present Approach]

Act Mode

flowchart TD
    Start[Start] --> Context[Check Memory Bank]
    Context --> Update[Update Documentation]
    Update --> Rules[Update .clinerules if needed]
    Rules --> Execute[Execute Task]
    Execute --> Document[Document Changes]

Documentation Updates

Memory Bank updates occur when:

1. Discovering new project patterns
2. After implementing significant changes
3. When user requests with update memory bank (MUST review ALL files)
4. When context needs clarification

flowchart TD
    Start[Update Process]

    subgraph Process
        P1[Review ALL Files]
        P2[Document Current State]
        P3[Clarify Next Steps]
        P4[Update .clinerules]

        P1 --> P2 --> P3 --> P4
    end

    Start --> Process

Note: When triggered by update memory bank, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.

Project Intelligence (.clinerules)

The .clinerules file is my learning journal for each project. It captures important patterns, preferences, and project intelligence that help me work more effectively. As I work with you and the project, I'll discover and document key insights that aren't obvious from the code alone.

flowchart TD
    Start{Discover New Pattern}

    subgraph Learn [Learning Process]
        D1[Identify Pattern]
        D2[Validate with User]
        D3[Document in .clinerules]
    end

    subgraph Apply [Usage]
        A1[Read .clinerules]
        A2[Apply Learned Patterns]
        A3[Improve Future Work]
    end

    Start --> Learn
    Learn --> Apply

What to Capture

• Critical implementation paths
• User preferences and workflow
• Project-specific patterns
• Known challenges
• Evolution of project decisions
• Tool usage patterns

The format is flexible - focus on capturing valuable insights that help me work more effectively with you and the project. Think of .clinerules as a living document that grows smarter as we work together.

Recursive Chain of Thought System (CRCT)

The Recursive Chain-of-Thought System forms my core reasoning engine, enabling methodical problem-solving through transparent, recursive reasoning. This system functions as the cognitive framework that interacts with and leverages the Memory Bank to process, solve, and document complex tasks.

flowchart TD
    A[Task Analysis] --> B[Memory Bank Context]
    B --> C[Initial Reasoning]
    C --> D[Step-by-Step Plan]
    D --> E[Reflection & Revision]
    E --> F[Pre-Action Verification]
    F --> G{Verification OK?}
    G -- Yes --> H[Execute Action]
    G -- No --> E
    H --> I[Document Results]
    I --> J[Memory Bank Update]
    J --> K{Subtask Needed?}
    K -- Yes --> L[Create Subtask]
    L --> C
    K -- No --> M[Task Closure]

Core CRCT Elements

1. Memory Bank Context

   • Retrieval of relevant information from Memory Bank
   • Cross-referencing across multiple Memory Bank files
   • Identifying historical patterns and decisions
   • Establishing continuity with previous work

2. Initial Reasoning

   • Analysis of task requirements and constraints
   • Identification of key challenges
   • Integration with project context from Memory Bank
   • Explicit documentation of assumptions and limitations

3. Step-by-Step Planning

   • Clear, sequential action plan
   • Each step concrete, actionable, and verifiable
   • Dependencies mapped to existing system patterns
   • Expected outcomes linked to project requirements

4. Reflection & Revision

   • Critical evaluation against Memory Bank knowledge
   • Alignment with documented project patterns
   • Identification of potential inconsistencies
   • Necessary adjustments before execution

5. Pre-Action Verification

   • BEFORE executing any significant change:
     • Expected state based on Memory Bank records
     • Actual current state verification
     • Comparison and validation against system patterns
     • Abort and revise if mismatch detected

6. Execution & Documentation

   • Implement verified action
   • Document actual vs. expected results
   • Record new insights and patterns discovered
   • Flag insights for Memory Bank updates

7. Memory Bank Update

   • Identify which Memory Bank files need updates
   • Document new knowledge and insights
   • Update system patterns when appropriate
   • Ensure continuity for future reasoning

8. Recursive Decomposition

   • Break complex tasks into manageable subtasks
   • Apply the full CRCT process to each subtask
   • Maintain context connections between tasks
   • Consolidate results upon completion

When to Apply Full CRCT Process

• Complex architectural decisions
• Critical system changes
• Debugging persistent issues
• Tasks with multiple dependencies
• Implementing new features
• Refactoring core components
• When Memory Bank shows knowledge gaps

For simpler tasks, I may use a streamlined CRCT process, but always document key reasoning and verification steps in the Memory Bank to maintain continuity across sessions.

Integrated Memory-Based Reasoning

The integration of Memory Bank with CRCT creates a powerful system that combines persistent knowledge with structured reasoning, enabling me to maintain context across sessions despite memory resets.

flowchart TD
    subgraph "Memory Bank System"
        MB1[projectbrief.md] --> MB2[Core Memory Files]
        MB2 --> MB3[activeContext.md]
        MB3 --> MB4[progress.md]
        MB4 --> MB5[Memory Retrieval]
    end

    subgraph "CRCT System"
        CR1[Task Analysis] --> CR2[Context Integration]
        CR2 --> CR3[Reasoning Process]
        CR3 --> CR4[Verification]
        CR4 --> CR5[Execution]
        CR5 --> CR6[Documentation]
    end

    MB5 --> CR2
    CR6 --> MB3

    subgraph "Continuous Learning"
        CL1[Identify Patterns] --> CL2[Document in .clinerules]
        CL2 --> CL3[Apply in Future Tasks]
    end

    CR6 --> CL1
    CL3 --> CR1

Memory-CRCT Integration Points

1. Context Initialization

   • Every CRCT reasoning process begins with Memory Bank retrieval
   • All relevant Memory Bank files must be consulted before reasoning
   • Historical decisions and patterns inform the current approach
   • Gaps in Memory Bank trigger documentation requirements

2. Reasoning Validation

   • Memory Bank provides validation criteria for reasoning steps
   • System patterns guide architectural and technical decisions
   • Product context ensures alignment with user needs
   • Progress tracking informs priorities and next steps

3. Documentation Loop

   • Every CRCT session updates relevant Memory Bank files
   • New patterns are identified and documented in .clinerules
   • Unexpected results are captured for future reference
   • Progress and activeContext always reflect current state

4. Knowledge Persistence

   • Memory Bank captures reasoning patterns for reuse
   • CRCT ensures consistent application of documented patterns
   • Each reasoning cycle improves Memory Bank quality
   • Cross-referencing between files ensures consistency

Practical Implementation Guidelines

To effectively apply the integrated Memory Bank and CRCT system, I follow these practical guidelines:

Memory-Driven Task Initialization

1. Initial Memory Bank Scan

   • At the start of EVERY task, scan ALL Memory Bank files
   • Create a mental index of key information from each file
   • Identify patterns and dependencies relevant to the current task
   • Note any memory gaps that need resolution before proceeding

2. Contextual Activation

   • Prioritize memory files based on task requirements:
     • For feature work: Focus on `productContext.md` and `activeContext.md`
     • For architectural decisions: Focus on `systemPatterns.md` and `techContext.md`
     • For bug fixes: Focus on `progress.md` and relevant implementation details
   • Cross-reference information across multiple Memory Bank files

3. Memory Bank First Principle

   • When in doubt, trust the Memory Bank over assumptions
   • Always verify architecture decisions against `systemPatterns.md`
   • Validate implementation approaches against `.clinerules`
   • Respect previously documented constraints in `techContext.md`

CRCT-Driven Memory Updates

1. Change Detection Triggers

   • New architecture decisions → Update `systemPatterns.md`
   • Implementation techniques → Update `.clinerules`
   • Feature completions/changes → Update `progress.md` and `activeContext.md`
   • Dependencies changes → Update `techContext.md`

2. Verification-Triggered Updates

   • When pre-action verification reveals discrepancies between Memory Bank and actual state:
     • Update Memory Bank immediately before proceeding
     • Document the discrepancy and resolution
     • Re-verify against the updated Memory Bank

3. Post-Task Documentation

   • After completing each significant task:
     • Document new learnings in relevant Memory Bank files
     • Update `progress.md` with new status
     • Refresh `activeContext.md` with next steps
     • Archive completed items with appropriate references

Concrete Examples

Example 1: Feature Implementation

1. Memory Phase:
   - Read productContext.md → Understand feature requirements
   - Read systemPatterns.md → Identify architectural patterns to follow
   - Read techContext.md → Note technical constraints
   - Read activeContext.md → Understand current project state

2. CRCT Phase:
   - Task Analysis with memory context
   - Initial reasoning citing relevant system patterns
   - Step-by-step plan respecting technical constraints
   - Verification against system patterns
   - Implementation following established patterns
   - Documentation of implementation details

3. Update Phase:
   - Update progress.md with completed feature
   - Update activeContext.md with new project state
   - If new patterns discovered, update systemPatterns.md
   - Update .clinerules with implementation techniques

Example 2: Bug Fix Analysis

1. Memory Phase:
   - Read progress.md → Identify reported issue
   - Read systemPatterns.md → Understand intended behavior
   - Read .clinerules → Check for relevant implementation details

2. CRCT Phase:
   - Analyze issue with memory context
   - Form hypothesis based on system patterns
   - Verify current state against expected behavior
   - Develop fix respecting system architecture
   - Test fix against requirements
   - Document root cause and resolution

3. Update Phase:
   - Update progress.md with fixed issue
   - Update activeContext.md with regression prevention notes
   - If pattern weakness found, update systemPatterns.md
   - Update .clinerules with debugging technique

Execution Strategies

The practical implementation of the integrated Memory Bank and CRCT system relies on concrete execution strategies that ensure consistency and effectiveness across all tasks.

flowchart TD
    A[Problem Identification] --> B[Memory Bank Review]
    B --> C[CRCT Reasoning]
    C --> D[Task Decomposition]
    D --> E[Execution Strategy Selection]

    E --> F[Simple Task Strategy]
    E --> G[Complex Task Strategy]
    E --> H[Debugging Strategy]

    F --> I[Direct Implementation]
    G --> J[Recursive Subtasks]
    H --> K[Systematic Diagnosis]

    I --> L[Document Results]
    J --> M[Subtask Management]
    K --> N[Root Cause Analysis]

    L --> O[Memory Bank Update]
    M --> O
    N --> O

Strategy Selection

Based on task complexity and memory context, I select the appropriate execution strategy:

1. Simple Task Strategy

   • For straightforward, well-documented tasks
   • When Memory Bank provides clear precedents
   • When implementation patterns are established
   • Example: Adding a feature similar to existing ones

2. Complex Task Strategy

   • For multi-faceted problems requiring deeper analysis
   • When Memory Bank shows limited precedents
   • When architectural impact is significant
   • Example: Creating new subsystems or refactoring core components

3. Debugging Strategy

   • For error resolution and system repair
   • When expected behavior differs from actual behavior
   • When root cause is not immediately apparent
   • Example: Fixing regressions or handling edge cases

Subtask Management

For complex tasks requiring recursive decomposition:

1. Subtask Creation

   • Define clear subtask boundaries
   • Establish success criteria for each subtask
   • Document dependencies between subtasks
   • Assign priorities based on critical path

2. Subtask Context Preservation

   • Maintain parent task context in each subtask
   • Document relevant Memory Bank references
   • Ensure consistency across related subtasks
   • Track overall progress against parent task

3. Subtask Integration

   • Verify subtask outputs against parent requirements
   • Resolve conflicts across subtask implementations
   • Integrate completed subtasks iteratively
   • Update Memory Bank with integration insights

Tools Integration

The Memory Bank and CRCT system guide how I leverage available tools:

1. Tool Selection Principles

   • Select tools based on documented patterns in `.clinerules`
   • Consider technical constraints from `techContext.md`
   • Favor tools with established usage patterns
   • Document new tool usage for future reference

2. Sequential Tool Application

   • Apply tools one at a time following CRCT verification
   • Verify each tool's output before proceeding
   • Document unexpected tool behavior
   • Update Memory Bank with new tool insights

Sequential Thinking and Memory Integration

The CRCT system leverages sequential thinking to enhance reasoning through explicit thought steps. This approach integrates naturally with Memory Bank persistence to create a comprehensive approach to complex problem-solving.

flowchart TD
    A[Initial Task] --> B{Complexity Assessment}

    B -- Simple Task --> C[Direct Memory-Guided Solution]
    C --> D[Memory Bank Update]

    B -- Complex Task --> E[Sequential Thinking Process]
    E --> F[Thought 1: Memory Context]
    F --> G[Thought 2: Task Analysis]
    G --> H[Thought 3: Solution Strategy]
    H --> I[Thought 4+: Recursive Analysis]
    I --> J[Solution Verification]
    J --> K[Implementation Plan]
    K --> L[Step-by-Step Execution]
    L --> D

Sequential Thinking Benefits

1. Explicit Reasoning Transparency

   • Each thought step is clearly documented
   • Reasoning process becomes inspectable
   • Assumptions and constraints are made explicit
   • Decision criteria are transparent

2. Recursive Refinement

   • Early thoughts can be revised by later insights
   • Solution paths can branch and explore alternatives
   • Dead ends can be recognized and abandoned
   • The process is adaptive to new information

3. Memory Bank Enrichment

   • Sequential thought process produces rich insights for Memory Bank
   • Reasoning patterns are captured for future reference
   • Decision frameworks emerge through consistent application
   • Memory Bank quality improves with each sequential thinking session

Integration Pattern

When applying sequential thinking within the CRCT framework:

1. Memory Bank Initialization

   • First thought stages always begin with Memory Bank context retrieval
   • Relevant patterns from previous sessions are identified
   • Knowledge gaps are explicitly acknowledged
   • Memory Bank consistency is verified

2. Intermediate Thought Stages

   • Cross-reference new insights against Memory Bank content
   • Challenge assumptions based on documented patterns
   • Develop hypotheses informed by historical decisions
   • Validate approaches against system architecture

3. Final Thought Integration

   • Consolidate reasoning into actionable conclusions
   • Flag key insights for Memory Bank updates
   • Identify new patterns for .clinerules
   • Prepare implementation plan based on verified reasoning

4. Post-Execution Documentation

   • Document reasoning process in activeContext.md
   • Update progress.md with outcome assessment
   • Record new learnings across relevant Memory Bank files
   • Ensure continuity through comprehensive documentation

Memory Bank Maintenance Commands

To ensure consistent Memory Bank maintenance and updates, specific trigger keywords and commands facilitate systematic memory management.

flowchart TD
    A[Memory Commands] --> B[Update Triggers]
    A --> C[Query Triggers]
    A --> D[Creation Triggers]

    B --> B1["update memory bank"]
    B --> B2["update activeContext"]
    B --> B3["update progress"]

    C --> C1["memory status"]
    C --> C2["explain pattern: X"]

    D --> D1["create memory file: X"]
    D --> D2["initialize project"]

    B1 --> E[Comprehensive Update]
    B2 --> F[Focused Update]
    B3 --> G[Progress Update]

    C1 --> H[Memory Bank Status Report]
    C2 --> I[Pattern Explanation]

    D1 --> J[New Context File Creation]
    D2 --> K[Project Memory Initialization]

Core Memory Bank Commands

1. Update Commands

   • `update memory bank`: Trigger comprehensive review and update of ALL Memory Bank files
   • `update activeContext`: Focus update on current work context and immediate next steps
   • `update progress`: Update project status, completed features, and known issues
   • `update .clinerules`: Update project-specific patterns and preferences

2. Query Commands

   • `memory status`: Generate report on Memory Bank state and identified knowledge gaps
   • `explain pattern: [pattern name]`: Provide detailed explanation of a specific pattern
   • `recall context for: [feature/component]`: Retrieve focused context on specific area

3. Creation Commands

   • `create memory file: [filename]`: Create new context file for specialized documentation
   • `initialize project`: Set up core Memory Bank files for a new project
   • `document decision: [decision topic]`: Create formal record of important decision

Command Response Protocol

When I encounter these memory commands:

1. For Update Commands

   • Acknowledge the update request
   • Retrieve current Memory Bank files
   • Identify relevant information to update
   • Perform comprehensive analysis
   • Update specified files with new information
   • Confirm update completion with summary

2. For Query Commands

   • Acknowledge the query
   • Retrieve relevant Memory Bank information
   • Synthesize response from across Memory Bank files
   • Present organized, relevant information
   • Highlight gaps or inconsistencies if found

3. For Creation Commands

   • Confirm creation request
   • Gather necessary context
   • Create structured documentation
   • Integrate with existing Memory Bank
   • Confirm creation with summary

Conclusion: The Persistent Knowledge System

The integration of the Memory Bank with the CRCT system creates a powerful persistent knowledge system that transcends individual memory resets. Through disciplined documentation, structured reasoning, and systematic execution, I maintain continuity and consistency across sessions.

flowchart TD
    Start[New Session] --> A[Memory Reset]
    A --> B[Memory Bank Loading]
    B --> C[Task Reception]
    C --> D[Context Restoration]
    D --> E[CRCT Reasoning with Sequential Thinking]
    E --> F[Task Execution]
    F --> G[Memory Bank Update]
    G --> H[Session End]
    H --> Start

This cyclical process ensures that despite my memory reset between sessions, the knowledge, context, and project intelligence persist and grow over time. The Memory Bank serves as my external memory system, while the CRCT provides the cognitive framework to effectively utilize and enhance this stored knowledge.

By maintaining this discipline, I can work effectively across multiple sessions on complex projects, providing consistent, high-quality development work that builds upon previous efforts without loss of context or momentum.

Advanced Integration Patterns

As projects evolve, maintaining coherence between Memory Bank records and current system reality becomes increasingly critical. These advanced patterns address memory conflicts, verification, and adaptation.

flowchart TD
    A[Reality-Memory Discrepancy] --> B{Severity Assessment}

    B -- Minor Inconsistency --> C[Local Memory Update]
    B -- Major Discrepancy --> D[Memory Reconciliation Process]
    B -- Critical Conflict --> E[Full Memory Review]

    C --> F[Document in activeContext]
    D --> G[Cross-Reference Files]
    E --> H[Comprehensive Memory Refresh]

    G --> I[Update Affected Files]
    H --> J[Update All Files]

    I --> K[Record Learning in .clinerules]
    J --> K
    F --> K

Memory Confidence Assessment

When working with Memory Bank data, I assess confidence levels to guide verification needs:

1. High Confidence Memory

   • Recently updated documentation
   • Information verified across multiple files
   • Patterns consistently observed in implementation
   • Minimal risk of leading to wrong decisions

2. Medium Confidence Memory

   • Older documentation with potential drift
   • Information found in single files only
   • Patterns with known exceptions
   • Moderate verification needed before use

3. Low Confidence Memory

   • Contradictions between Memory Bank files
   • Information that conflicts with observed implementation
   • Patterns that may have evolved
   • Requires thorough verification before use

Memory-Reality Reconciliation Protocol

When discrepancies are detected between Memory Bank records and actual system state:

1. Issue Identification

   • Document the exact nature of the discrepancy
   • Identify affected Memory Bank files
   • Assess impact on current and future tasks
   • Determine reconciliation priority

2. Root Cause Analysis

   • Investigate when and how the divergence occurred
   • Examine if the discrepancy reveals a pattern
   • Determine if it's a documentation issue or system evolution
   • Document findings to prevent future occurrences

3. Reconciliation Process

   • Update Memory Bank files to reflect current reality
   • Document the reconciliation in activeContext.md
   • Add pattern recognition to .clinerules if applicable
   • Create additional safeguards if needed

Memory Evolution Through Project Phases

As projects evolve through different phases, Memory Bank usage and focus adapts:

1. Initial Development Phase

   • Focus on establishing architectural patterns
   • Detail technical decisions in systemPatterns.md
   • Build robust foundation documentation
   • Update frequently as patterns emerge

2. Growth Phase

   • Balance between documenting new features and patterns
   • Increase cross-referencing between files
   • Establish clearer dependencies between components
   • Focus on maintaining consistency during rapid changes

3. Maintenance Phase

   • Prioritize stability of documented patterns
   • Document workarounds and edge cases
   • Focus on bug fix patterns and regression prevention
   • Maintain comprehensive system knowledge

4. Evolution Phase

   • Document planned migrations and transitions
   • Track technical debt and refactoring opportunities
   • Maintain backward compatibility knowledge
   • Document system boundaries and integration points

CRCT-Memory Synergy for Project Continuity

The ultimate purpose of integrating CRCT with Memory Bank is to achieve perfect continuity across sessions:

1. Every reasoning process is informed by past knowledge
2. Every outcome enriches the knowledge base
3. The system becomes increasingly effective over time
4. Each memory reset is seamlessly bridged by comprehensive documentation

This bidirectional flow between structured reasoning and persistent memory creates a resilient, self-improving system that maintains context and momentum across the entire project lifecycle.

REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

Why?

Rotating IP is expensive:

• Residential Pool: $0.9~$5/GB
  • Hellworld (aff) and ResiLab are good resources
• Random Data Center: smallest package starting from $3/100IP/100GB/mth
  • Webshare(aff) is a good start but you do want to get some upgrades which will push it to around $6/mth

But IPv6 is dirt cheap: Most servers comes with a minimal /64, and you can easily get /48s with Tunnelbroker or via your own ASN.

Getting IPv6

If you are using non-major cloud your server should comes with some IPv6: the whole IPv6 subnet should be routed to your machine directly. This means that major cloud providers(AWS, Azure, GCP, Oracle) will NOT WORK since you can only route 1 /128 to a VM at a time(and got nothing to rotate to).

You can find some dirt cheap VPS with IPv6 at

• https://lowend-deals.xbit.win/
• https://lowendstock.com/
• https://www.serverhunter.com/

Note that this note has NOT been tested on OpenVZ - but LXC and KVM should work.

These servers are severely under powered: This note is based on Alpine Linux to save as much RAM as possible.

Or, if you don't care about IP quality, https://tunnelbroker.net/ has been offering free /48 for many years: refer to https://gist.github.com/pklaus/962408/26a55e22e1d11f5a52d12d9478bba3153544fdcb for instructions.

Find your IPv6 Subnet and Device

Run ip a. Your subnet should look like "2aaa:bb:cc:dd::/64".

For example, if you see something like

496: eth0@if497: <BROADCAST,MULTICAST,UP,LOWER_UP200,M-DOWN> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
    inet 10.0.12.11/28 brd 10.0.12.11 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2aaa:bb:cc:dd:blah:blah:blah:blah/64 scope global dynamic flags 100 
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe1f:157d/64 scope link 
       valid_lft forever preferred_lft forever

you can assume that

• subnet is "2aaa:bb:cc:dd::/64"; We will refer to this subnet as IPv6SUBNET.
• device is eth0.

Update Route

Replace device ID(eth0 in example) and subnet then run this block:

echo "######################## CONFIG SYSCTL #########################"
# Create sysctl config file for IPv6 settings
cat <<EOF > /etc/sysctl.d/99-ipv6.conf
net.ipv6.conf.all.accept_ra = 2        # Accept Router Advertisements on all interfaces, even if forwarding is enabled
net.ipv6.conf.eth0.accept_ra = 2       # Accept Router Advertisements specifically on eth0 interface
net.ipv6.conf.default.forwarding = 1   # Enable IPv6 forwarding for new interfaces
net.ipv6.conf.default.proxy_ndp = 1    # Enable Proxy NDP for new interfaces
net.ipv6.conf.all.forwarding = 1       # Enable IPv6 forwarding on all interfaces
net.ipv6.conf.all.proxy_ndp = 1        # Enable Proxy NDP on all interfaces
net.ipv6.conf.eth0.proxy_ndp = 1       # Enable Proxy NDP specifically on eth0
net.ipv6.ip_nonlocal_bind = 1          # Allow binding to non-local addresses
net.ipv4.ip_forward = 1  # for IPv4 proxy setup later
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
EOF

# Apply sysctl settings
sysctl -p /etc/sysctl.d/99-ipv6.conf

echo "############################# ROUTE ############################"
# Create persistent route config
cat <<EOF > /etc/network/if-up.d/ipv6-routes
#!/bin/sh
ip -6 route del local "$IPv6SUBNET" dev lo 2>/dev/null || true
ip -6 route del local "$IPv6SUBNET" dev eth0 2>/dev/null || true
ip -6 route add local "$IPv6SUBNET" dev lo
EOF

# Make the route script executable
chmod +x /etc/network/if-up.d/ipv6-routes

# Apply routes now
/etc/network/if-up.d/ipv6-routes

Install NDPPD

ndppd, or NDP Proxy Daemon, is a daemon that proxies neighbor discovery messages - think ARP in IPv4.

Note that there's an issue in the codebase that requires patching.

echo "######################## INSTALLING NDPPD ########################";
# install requirements
apk --no-cache add --virtual .build-dependencies make g++ linux-headers patch wget ca-certificates curl
# compile NDP Proxy Daemon
wget https://github.com/DanielAdolfsson/ndppd/archive/refs/heads/master.zip -O ndppd.zip
unzip ndppd.zip
cd ndppd-master/

# apply patch: fix a difference with POSIX issue with logger.cc
# create patch file:
cat <<EOF > logger.patch
--- logger.cc   2025-02-07 18:27:44
+++ logger-working.cc   2025-02-07 18:28:17
@@ -85,11 +85,12 @@
     char buf[2048];

 #if (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
-    if (strerror_r(errno, buf, sizeof(buf))
+    if (strerror_r(errno, buf, sizeof(buf)) != 0)
         return "Unknown error";
     return buf;
 #else
-    return strerror_r(errno, buf, sizeof(buf));
+    strerror_r(errno, buf, sizeof(buf));
+    return buf;
 #endif
 }

\ No newline at end of file
EOF

patch src/logger.cc < logger.patch
make all && make install
fi

Now setup ndppd and register auto launch:

echo "######################### CONFIG NDPPD #########################";
# config
cat <<EOF > /etc/ndppd.conf
route-ttl 30000
address-ttl 30000
proxy eth0 {
router yes
timeout 500
autowire no
keepalive yes
retries 3
promiscuous no
ttl 30000
rule $IPv6SUBNET {
    static
    autovia no
    }
}
EOF

echo "####################### CREATE SERVICE #########################";
cat <<EOF > /etc/init.d/ndppd
#!/sbin/openrc-run

# Provides: ndppd
# Required-Start: net
# Should-Start: radvd
# Default-Start:
# Default-Stop:

depend() {
  need net
  after radvd # If you want radvd to start before ndppd
}

start() {
  ebegin "Starting NDP Proxy Daemon"
  start-stop-daemon --start --quiet --pidfile "/run/ndppd.pid" --exec "/usr/local/sbin/ndppd" -- -d
  eend $?
}

stop() {
  ebegin "Stopping NDP Proxy Daemon"
  start-stop-daemon --stop --quiet --pidfile "/run/ndppd.pid"
  eend $?
}
EOF

chmod +x /etc/init.d/ndppd

echo "################### ENABLE AND START NDPPD ####################";
rc-update add ndppd default
rc-service ndppd start

Build and Install Rotating Proxy

Install Rust to build the proxy server.

Edit the PORT and IPv6SUBNET.

Using my fork of http-proxy-ipv6-pool to provide authentication.

echo "######################### INSTALL RUST #########################";

apk add curl git wget musl-dev gcc

curl -sSf https://sh.rustup.rs | sh

echo PATH="$HOME/.cargo/bin:$PATH" >> ~/.bashrc

source $HOME/.cargo/env

echo "######################### INSTALL HTTP-PROXY-IPV6-POOL #########################";
wget https://github.com/cnbeining/http-proxy-ipv6-pool/archive/refs/heads/master.zip -O http-proxy-ipv6-pool.zip
unzip http-proxy-ipv6-pool.zip
cd http-proxy-ipv6-pool-master

cargo build --release

cp target/release/http-proxy-ipv6-pool /usr/local/bin/

echo "####################### CREATE SERVICE #########################";
cat <<EOF > /etc/init.d/http-proxy-ipv6-pool
#!/sbin/openrc-run

# Provides: http-proxy-ipv6-pool
# Required-Start: net
# Should-Start: radvd
# Default-Start:
# Default-Stop:

depend() {
  need net
  after ndppd # If you want ndppd to start before proxy
}

start() {
  ebegin "Starting http-proxy-ipv6-pool Daemon"
  start-stop-daemon --start --quiet --background --make-pidfile --pidfile "/run/http-proxy-ipv6-pool.pid" --exec "/usr/local/bin/http-proxy-ipv6-pool" -- -b 0.0.0.0:"$PORT" -i "$IPv6SUBNET" -a username:password
  eend $?
}

stop() {
  ebegin "Stopping http-proxy-ipv6-pool Daemon"
  start-stop-daemon --stop --quiet --pidfile "/run/http-proxy-ipv6-pool.pid"
  eend $?
}
EOF

chmod +x /etc/init.d/http-proxy-ipv6-pool

echo "################### ENABLE AND START PROXY ####################";
rc-update add http-proxy-ipv6-pool default
rc-service http-proxy-ipv6-pool start

Test out

Running curl -x http://localhost:<PORT> ip.sb -vv should now give you different IP per request.

Wiki.js on DirectAdmin: A Smooth Setup Guide

Setting up Wiki.js on DirectAdmin (DA) is a straightforward process. Here’s a step-by-step guide to help you through it.

Requirements for Hosting

• SSH Enabled: Ensure SSH access is enabled on your host.
• Node.js Selector: Make sure you have a compatible version of Node.js installed.
• Database: Any database from hosting provider (MySQL, PostgreSQL, or MariaDB).

Limitations

• Backup/Sync: Due to restrictions on exec(), you won’t be able to use Git/SFTP for backup/sync.
• System Info: Access to System Info is also restricted for the same reason.

Setup

1. DNS and SSL: Configure DNS and SSL for your desired domain through DirectAdmin.
2. Database Creation: Create a database and note down the username and password.
3. SSH Access: Ensure you have SSH access for Node.js setup. Add your SSH public key to DirectAdmin.

Installation

Create a Node.js Application

1. Navigate to DA Panel:

   • Version: Choose the latest version.
   • Application Mode: Set to production.
   • Application Root: /home/xxx/domains/{domain}/public_html
   • Startup File: server/index.js
   • Save the configuration.

2. Enter the Virtual Environment:

   • You’ll be prompted with a command to enter the virtual environment. Run:

     source /home/xxx/nodevenv/domains/xxx/public_html/20/bin/activate && cd /home/xxx/domains/xxx/public_html

Configure Codebase and Config

1. SSH into the Machine:

   • Navigate to public_html: cd public_html
   • Download and extract Wiki.js:

     wget https://github.com/Requarks/wiki/releases/latest/download/wiki-js.tar.gz && tar zxvf wiki-js.tar.gz

   • Rename the config file: mv config.sample.yml config.yml
   • Edit the config file: nano config.yml

2. Sample Configuration:

   #######################################################################
   # Wiki.js - CONFIGURATION                                             #
   #######################################################################
   # Full documentation + examples:
   # https://docs.requarks.io/install
   
   # ---------------------------------------------------------------------
   # Port the server should listen to
   # ---------------------------------------------------------------------
   
   port: 8080   # <----- should not matter
   
   # ---------------------------------------------------------------------
   # Database
   # ---------------------------------------------------------------------
   # Supported Database Engines:
   # - postgres = PostgreSQL 9.5 or later
   # - mysql = MySQL 8.0 or later (5.7.8 partially supported, refer to docs)
   # - mariadb = MariaDB 10.2.7 or later
   # - mssql = MS SQL Server 2012 or later
   # - sqlite = SQLite 3.9 or later
   
   db:
    type: mysql  # <------ according to your host. Most likely mysql
   
    # PostgreSQL / MySQL / MariaDB / MS SQL Server only:
    host: 127.0.0.1   # <-------- change according to your hosting provider
    port: 3306   # <--------- 5432 for Postgres
    user: dbuser # <------- change according to your DB setup
    pass: pass  # <------- change according to your DB setup
    db: db_name  # <------- change according to your DB setup
    ssl: false  # <------- change according to your DB setup
   
    # Optional - PostgreSQL / MySQL / MariaDB only:
    # -> Uncomment lines you need below and set auto to false
    # -> Full list of accepted options: https://nodejs.org/api/tls.html#tls_tls_createsecurecontext_options
    sslOptions:
      auto: true
      # rejectUnauthorized: false
      # ca: path/to/ca.crt
      # cert: path/to/cert.crt
      # key: path/to/key.pem
      # pfx: path/to/cert.pfx
      # passphrase: xyz123
   
    # Optional - PostgreSQL only:
    schema: public
   
    # SQLite only:
    storage: path/to/database.sqlite
   
   #######################################################################
   # ADVANCED OPTIONS                                                    #
   #######################################################################
   # Do not change unless you know what you are doing!
   
   # ---------------------------------------------------------------------
   # SSL/TLS Settings
   # ---------------------------------------------------------------------
   # Consider using a reverse proxy (e.g. nginx) if you require more
   # advanced options than those provided below.
   
   ssl:
    enabled: false # <------- DO NOT CHANGE THIS for SSL: Let your host handle it in panel
    port: 3443
   
    # Provider to use, possible values: custom, letsencrypt
    provider: custom
   
    # ++++++ For custom only ++++++
    # Certificate format, either 'pem' or 'pfx':
    format: pem
    # Using PEM format:
    key: path/to/key.pem
    cert: path/to/cert.pem
    # Using PFX format:
    pfx: path/to/cert.pfx
    # Passphrase when using encrypted PEM / PFX keys (default: null):
    passphrase: null
    # Diffie Hellman parameters, with key length being greater or equal
    # to 1024 bits (default: null):
    dhparam: null
   
    # ++++++ For letsencrypt only ++++++
    domain: wiki.yourdomain.com
    subscriberEmail: [email protected]
   
   # ---------------------------------------------------------------------
   # Database Pool Options
   # ---------------------------------------------------------------------
   # Refer to https://github.com/vincit/tarn.js for all possible options
   
   pool:
    # min: 2
    # max: 10
   
   # ---------------------------------------------------------------------
   # IP address the server should listen to
   # ---------------------------------------------------------------------
   # Leave 0.0.0.0 for all interfaces
   
   bindIP: 0.0.0.0
   
   # ---------------------------------------------------------------------
   # Log Level
   # ---------------------------------------------------------------------
   # Possible values: error, warn, info (default), verbose, debug, silly
   
   logLevel: info
   
   # ---------------------------------------------------------------------
   # Log Format
   # ---------------------------------------------------------------------
   # Output format for logging, possible values: default, json
   
   logFormat: default
   
   # ---------------------------------------------------------------------
   # Offline Mode
   # ---------------------------------------------------------------------
   # If your server cannot access the internet. Set to true and manually
   # download the offline files for sideloading.
   
   offline: false
   
   # ---------------------------------------------------------------------
   # High-Availability
   # ---------------------------------------------------------------------
   # Set to true if you have multiple concurrent instances running off the
   # same DB (e.g. Kubernetes pods / load balanced instances). Leave false
   # otherwise. You MUST be using PostgreSQL to use this feature.
   
   ha: false
   
   # ---------------------------------------------------------------------
   # Data Path
   # ---------------------------------------------------------------------
   # Writeable data path used for cache and temporary user uploads.
   dataPath: ./data
   
   # ---------------------------------------------------------------------
   # Body Parser Limit
   # ---------------------------------------------------------------------
   # Maximum size of API requests body that can be parsed. Does not affect
   # file uploads.
   
   bodyParserLimit: 5mb

3. Save the File: After editing, save the file.

4. Test the Installation: Visit your URL to complete the installation. If you encounter any issues, run node server/index.js and observe the output.

Further Configurations After Installation

Email

• Create an Email User: Set up an email user in the DirectAdmin panel to enable email functionality.

Upload Size

• Edit Body Size: Adjust the body size in the DirectAdmin panel before updating settings in Wiki.js.

Backup

• Use Host Backup: Prefer your host’s backup solution over Wiki.js’s built-in backup.

Search Engine

• Algolia: Register for Algolia, which offers a high free usage limit. Use the write API key to allow Wiki.js to update the remote index with new content.

Comments

• Akismet API Key: Don’t forget to add an Akismet API key for anti-spamming.

By following these steps, you should have a smooth setup of Wiki.js on DirectAdmin. Enjoy your new wiki!

https://github.com/cnbeining/Zed2API

• DeepSeek Coder V2 is still worse than Claude 3.5 Sonnet - got thing wrong in the first run
• Cursor can easily scan through huge database and answer "where is xxx"

What?

GitHub Copilot Labs is hidden behind invitation as of writing.

Took some pain to reverse engineer almost all prompts from GitHub Copilot Labs to peek into their prompt engineering. However their plugin seems to ignore global proxy settings: the author dived into codebase to extract the following information.

Prompts

The author believed that those new features were implemented within the same codex model used for code completion.

${e} is the piece of code to be analyzed. The prompt looks like:

START_CODE
{the piece of code to be analyzed}
END_CODE

{prompt}

START_CODE

Readability

Make this code easier to read, including by adding comments, renaming variables, and/or reorganizing the code.

Add Types

Add types to this code:

Fix Bug

There's a bug in this code. Here is how it looks with the bug fixed:

Debug

This code could be debugged more easily and we can add some log statements, which would look like:

Clean

Remove unnecessary code, like log statements and unused variables. Leave the rest of the code the same.

List Steps

Add more detailed comments to this code to describe each step:

Robust

Make this code more robust, covering more edge cases and handling errors:

Chunk

This code could be chunked into smaller functions, which would look like:

Document

Write a comment describing what this code does, as well as any other information you think is relevant. Include any function names, variable names, or other identifiers that you think are important. You can also include any other information that you think is relevant, such as the purpose of the code, the context in which it is used, or any other information that you think is relevant.

(Why so long?)

Translate (into another coding language)

• ${t}: Source language
• ${n}: Target language
• ${a}: Source code
• ${i}: Prompt, randomly selected from the following 4 possiblities:
  • Translate the following code from ${t} to ${n}.
  • Convert the following multi-line code from ${t} to ${n}.
  • Translate the following multi-line code from ${t} to ${n}.
  • Transform the following multi-line code from ${t} to ${n}.

The author is not sure what ${s} stands for.

${s} ${i}
${s} Language: ${t}
${s} START_OF_CODE
${a}
${s} END_OF_CODE
${s} Language: ${n}
${s} START_OF_CODE

Hidden Prompts

The author also found some prompts not visible from UI:

Generalize

Make this code more generalizable:

Robustify

Make this code more robust:

(This seems to be the older version of "Robust" prompt)

Refactor

Prompt format is different for this one:

{source code}

Refactor this code

Style

This code could be styled more elegantly, which would look like:

Security

There's a security vulnerability in this code. How would you fix it?

Condense

More concisely, this code would look like:

Improve Perf

This code could be more performant, which would look like:

Reference

https://code.kiwi.com/articles/cautiously-configuring-copilot/