Function consolidation and descriptive docstrings

UI library · Desktop guide · Project edit workflow

Tech Connector can audit a Python project for repeated function implementations before an agent edits or removes code. This is a structural source analysis, not a name-only search and not a model guess.

Find identical implementations

Ask in Chat with the project folders in scope. For example:

Find identical or similar functions across this project. Choose the best canonical owner, replace every verified usage, and clear out duplicates only after imports, calls, tests, registrations, and dynamic references are safe.

The dedicated consolidation path:

1. Parses the bounded Python project scope and inventories functions and methods.
2. Normalizes function names, argument names, and local-variable names when it fingerprints executable structure.
3. Preserves meaningful differences such as called APIs, accessed attributes, constants, control flow, signature shape, and return behavior.
4. Groups structurally identical implementations even when their argument or local-variable names differ.
5. Ranks a proposed canonical owner using unambiguous usage evidence, public visibility, existing documentation, and type annotations.
6. Reports direct calls, imports, and other name references when a symbol name resolves unambiguously within the scanned project.
7. Flags string-based or dynamic lookup evidence for manual proof before removal.

This behavior is covered by executable tests, including two identical helpers whose parameter names differ.

Exact duplicates versus similar functions

Tech Connector deliberately keeps these results separate:

• Structurally identical callable groups are exact normalized implementation matches within the scanned source boundary. They are strong consolidation candidates, subject to caller and external-API verification.
• Similar callable review candidates share substantial structural features, but are advisory evidence only. A similar body can still have different validation, side effects, exceptions, constants, defaults, or return meaning.

Similarity never becomes automatic proof that one function can replace another. The agent is instructed to compare contracts and tests, and to retain both implementations when behavioral equivalence is not established.

Repeated protocol methods on unrelated classes, such as ordinary to_dict() implementations, are filtered out of exact consolidation recommendations when their shared method shape alone would be misleading.

Safe replacement sequence

For a consolidation edit, Tech Connector supplies this required order:

1. Select the canonical owner from evidence.
2. Replace verified imports, direct calls, qualified calls, tests, registrations, and configuration references.
3. Preserve a compatibility wrapper when external callers may depend on an old public name, signature, or default.
4. Re-scan for each retired symbol.
5. Run focused tests and inspect remaining dynamic-reference warnings.
6. Remove the duplicate only after those checks pass.

The scan is bounded to protect responsiveness on large repositories. Its report states the number of files and callables inspected. Anything outside the active project roots, generated at runtime, loaded by plugins, or used by an external consumer remains an explicit verification boundary.

Add descriptive docstrings

Open a Python file in Editor, optionally select the functions to update, and choose Studio > Add Missing Docstrings. You can also ask in Chat:

Add clear docstrings to the functions in this file. Describe every argument and the return value.

The action preserves executable statements and meaningful existing prose. For new or incomplete documentation it adds:

• a concise behavioral summary for the function;
• one :param name: entry for every non-self and non-cls argument;
• parameter roles inferred from established names such as source paths, destinations, callbacks, limits, settings, mappings, and flags;
• type annotations and default values when the signature provides them;
• an explicit :return: contract, including None for side-effect functions.

It also replaces placeholders such as :param path: path and :return: result while leaving specific human-written descriptions intact.

Example output:

def export_asset(
    source_path: str,
    destination_path: str,
    overwrite: bool = False,
) -> str:
    """Exports asset.

    :param source_path: Filesystem path of the source resource. Expected type: ``str``.
    :param destination_path: Filesystem path where the result is written. Expected type: ``str``.
    :param overwrite: Whether an existing destination may be replaced. Expected type: ``bool``. Defaults to ``False``.
    :return: The asset produced by the function as ``str``.
    """

After the edit, Chat reports which functions received new docstrings, which existing docstrings were repaired, and which argument contracts were documented.